CAN busz (+SPI converter) és Raspberry Pi topológia, működés, kiépítés

 ( KaTT | 2019. június 17., hétfő - 18:16 )

Sziasztok!

A 20+ szenzor sok helyiségben (házi, építsd magadnak, ha tudod, ha nem, akkor pedig kérdezz nagy hülyeségeket) projekt következő lépésénél tartok.
Az I2C buszon 2 környező helyiség szenzorait fogom olvasni, azonban a messzebbi helyiségekben CAN buszt fogok várhatóan használni és ennek a kiépítésének, tervezésének a lépéseit próbálom összeszedni. Megosztom az infókat, amire jutottam.

Bevezető kérdés: ha a távolság miatt elegendő az I2C busz is, mert pár métert kell vinni, és a szenzor is támogatja az I2C-n kívül az SPI-t is, van értelme pár szenzort csak I2C buszon kezelni vagy átgondoltabb lenne akkor már mindent a CAN buszon vinni és SPI-n keresztül elérni a szenzorokat?
Lehet egyszerre az RPI-n I2C és SPI is, csak várhatóan melyik terheli jobban majd az RPI-t, ha I2C + CAN(SPI) van, vagy ha csak CAN(SPI), azonos szenzor szám esetén?
Van számottevő overhead-je a CAN-SPI átalakításnak?

Visszatérve a fő témára:

CAN busz topológia lehetőségek: =============================
- vonal / busz
- csillag (CAN busz HUB szükséges)
- gyűrű
- (továbbá lehet egymásba is fűzni, hogy a vonal/busz x. eleme után lesz csillag, stb.)

http://www.mindsensors.com/content/86-can-and-its-topology

Csillag CAN busz topológiához HUB szükséges: (olyan mint a HUP, csak teljesen más ;)

CAN busz HUB: =============================

http://www.mindsensors.com/frc/184-splitter-for-can-network

https://www.avire-global.com/products/emergency-telephones/dcp-accessories/can-bus-splitter/

Ami számomra itt érdekes, hogy a CAN busz HUB-ot lehet egymásba kötni, tehát gyakorlatilag 100+ eszköz lehet egy buszon, ami jelen esetben biztosan elég lesz.
Hogy hány, az függ a BUSZ verziójától: CAN 2.0A 11 bites azonosítót használ (2048 node), a CAN 2.0B pedig 29 biteset (536870912 node, ez még gombócból is sok!).

A fenti szenzor észszerű megtervezés, elrendezés a cél.

(Itt akkor az egyik HUB-on a terminator-t be kell kapcsolni.)

Tud ilyet is, itt látszik a terminator:

Kábelezés: =============================

https://tekeye.uk/automotive/can-bus-cable-wiring

Eszközös Raspberry Pi-hez:

Ez jónak tűnik:
https://www.elektor.com/pican-2-can-bus-board-for-raspberry-pi

Duál CAN busz:
http://www.industrialberry.com/canberrydual-v2-1/

Can busz shield V2.1 izolált, ez tűnik a legjobb választásnak:
http://www.industrialberry.com/canberry-v-2-1-isolated/
(Biztos van rá magyarázat, hogy miért kell a real-time clock mellé egy elem, mert több ilyen busz kezelő eszközön van RTC + elem. Mi van, ha lemerül az elem, mi fog változni? Mi van, ha merül?)

Vagy inkább ez.
http://www.industrialberry.com/canberrydual-iso-v2-1/

Itt mi a főbb különbség a canberrydual-v2-1 és canberrydual-iso-v2-1 között?

Ez kevésbé tűnik hasznosnak az előbbiekhez képest, de lehetőség:
https://www.elektor.com/cangineberry-active-cancrypt-and-canopen-module-for-rpi

Szóval ha szeretnék például bekötni 14 szenzort CAN buszon csillagpontosan, és a ez a termék 6 portos:

http://www.mindsensors.com/frc/184-splitter-for-can-network

HUB#1: PORT#1: RPI-be
HUB#1: PORT#2: HUB#2 port 1-be
HUB#1: PORT#3: HUB#3 port 1-be
HUB#1: PORT#4: HUB#4 port 1-be
HUB#1: PORT#5: (üres)
HUB#1: PORT#6: (üres)

HUB#2: PORT#1: HUB#1 port 2-be
HUB#2: PORT#2: szenzor 1
HUB#2: PORT#3: szenzor 2 
HUB#2: PORT#4: szenzor 3
HUB#2: PORT#5: szenzor 4 
HUB#2: PORT#6: szenzor 5 

HUB#3: PORT#1: HUB#1 port 3-ba
HUB#3: PORT#2: szenzor 6
HUB#3: PORT#3: szenzor 7
HUB#3: PORT#4: szenzor 8
HUB#3: PORT#5: szenzor 9
HUB#3: PORT#6: szenzor 10

HUB#4: PORT#: HUB#1 port 4-be
HUB#4: PORT#: szenzor 11
HUB#4: PORT#: szenzor 12
HUB#4: PORT#: szenzor 13
HUB#4: PORT#: szenzor 14
HUB#4: PORT#: TERMINÁTOR (TERMINAL OUT)

Akkor így megfelelő lesz?

A kérdés, ha helyiségenként általában 2-3 szenzor lesz, lehet-e láncba kötni, vagy máshogyan, hogy helyiségenként 1 kábel elég legyen?

A szerintem ROSSZ megoldás: (hogy kisbetu is hozzá tudjon szólni :)

Itt fent az a hiba szerintem, hogy maximum 1 terminátor lehet egy CAN buszon, és itt több van.
Szerintem nem jó, mert kevert topológia.

Ez a lenti kép így működhet? Költői kérdés, nem kell 2 node egymásra kötve az én esetemben, ez is szándékos rossz példa.


A sorba kötés elve alapján működhet akár. (De nem jó, mert felesleges 1 helyiségbe 2 node-ot húzni!)
Szerintem ez sem jó, mert kevert topológia és értelmetlenül van +1 node a helyiségben.

A talán biztosan jó megoldás, hogy node-onként csillagpontosan lesz összekötve:

Ahol az egyik utolsó node-ban bekapcsolom, hogy a TERMINAL OUT legyen (TERMINATOR). Vagy rakhatnék ellenállást is, de miért, ha tudja a CAN busz HUB.
Jól gondolom, hogy ebben az esetben 1 terminátor kell, és nem több, nem kevesebb?

További változat, hogy helyiségenként 1 node lesz kiépítve, és oda rakok CAN busz - SPI konvertert:

https://www.electrodragon.com/product/mcp2515-can-receiver-breakout-board-spi/
https://www.dx.com/p/mcp2515-can-bus-module-tja1050-receiver-spi-module-blue-2071076#.XQe1FXaWaUk

És erre az SPI konverterre rakom a 2-3 szenzort, lásd a képen, pár szenzorral lerajzolva:

Tehát a fenti kép alapján a szenzor 1-2-3 összesen 4 éren van a helyiségbe vezetve CAN buszon, majd SPI-re alakítva rákötöm mindhárom szenzort. Továbbá helyiségenként ugyanígy kötöm be, az 1-3 szenzort. (Hogy az SPI-t hogy kötöm, az külön kérdés :)
Van ennél észszerűbb kiépítése sok helyiség, 20+ szenzor esetén, ahol akár 30 méter távolságra is el kell vezetni a CAN buszt?

Triviális kérdésnek tűnik, de ebben az esetben csak SPI-t támogató szenzorokat használhatok, kivéve, ha meg lesz oldva más interface-re az átalakítás CAN buszról, jól értem?

Szenzor bekötés: =============================

4 ér kell, én CAT6A / CAT7A S/FTP-ben fogom húzni. Kettőt a CAN busznak, kettőt a 3.3VDC + föld.

Megfelelő a 2 datát egy érpárban, és a 2 powert egy érpárban vezetni, mint a képen?
Esetleg a maradék 4 érpárt lehet egyéb gyenge áramú feladatra használni, például RJ45-be kikötni, mint 100 mbit LAN port? Vagy legyen szépen üresen?
A 8 érpár esetén mind a 4 eret 1-1 érpárban vigyek külön, és a maradék 4 érpárt pedig hagyjam üresen?

Köszönöm előre is az észrevételeket.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

"(Biztos van rá magyarázat, hogy miért kell a real-time clock mellé egy elem, mert több ilyen busz kezelő eszközön van RTC + elem. Mi van, ha lemerül az elem, mi fog változni? Mi van, ha merül?)"

Számítógépet használtál már?
Ott miért van a BIOS mellett elem?

Már megint gondolkodás nélkül kérdezel, de így is szeretünk.

Igen. PC-n azért van elem, hogy ha áram nélkül van az eszköz, akkor se felejtse el az időt. Azonban az RPI boot után NTP-n tudja magát szinkronizálni, hogy mennyi a pontos idő, tehát ez sem indok, hogy miért lenne szükséges.

"Many time critical applications, e.g. measurement devices, require a real-time clock with an accuracyin the order of microseconds. In a centralised system this is easy to implement with standard timerdevices. But in a distributed system, where accurate time may be needed in different physicallocations, this is more difficult to achieve as there is no global system tick."

Egy RTC RPI leírásból: "I2C Real Time Clock modul Raspberry PI-hez: backup elemmel ellátott valósidejű óra modul (RTC). Tökéletesen alkalmas arra az esetre, ha a Raspberry PI boot-olásakor nincs hálózatra kötve, de szükséges a pontos időt használni. Például adat loggolásnál, időbélyegző használatakor, óraépítéshez, időzítő készítéshez stb...
A DS1307-es a legnépszerűbb RTC eszköz. 5V-os tápigénye miatt használható ARDUINO-hoz is iletve bármilyen TTL jelszintű mikrokontrollerhez, "

Egy páratartalom vagy fényerősség szenzornak működnie kellene RTC nélkül is nyilván.
Tehát az a pontos kérdésem, hogy milyen hátrányom van, ha RPI + CAN + SPI + szenzorok esetén nincs elem az RTC elem tartójában (ha egy erős szünetmentes tápegységen van az összes RPI, összes szenzor és minden, sőt, még az elsődleges és másodlagos internet is, tehát internet van). Ha megy, akkor van hálózat, és van NTP által pontos idő is.

Amúgy az összes kérdésem sokkal fontosabb, mint ez a zárójelbe tett, de hát mindenki abból csemegézik, ami neki tetszik... :)

Sakk-matt,
KaTT :)

Ha a büdös életbe nem fogod használni az RTC-t, akkor minek teszed fel? Csak fogyaszt fölöslegesen. És ha nem használod, akkor elem se kell rá. És ha nincs rajta elem, akkor az nem fog lemerülni.

A számítógép is elindul és NCP-n tud szinkronizálni. Az elem egyszerűen azért van, hogy ne felejtse el az időt a gép. Ha van ütemezett feladatod, watchdog vagy bármi másnak szüksége lehet az időre "kikapcsolt" állapotban is. Ha te hardveresen kikapcsolod a gépet mindig és kikapcsolt állapotban illetve boot során nincs szükséged a pontos időre, akkor nem kell neked RTC.
---
- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

Szia, szünetmentesen lesz végig a gép, és elvileg 0/24-ben menni fog, amiben a szenzorok vannak. Azt hittem, van valami szenzorral kapcsolatos oka, hogy kell RTC, de nem akkor.

Sakk-matt,
KaTT :)

De hát leírták: pontosan szenzorral kapcsolatos oka van.
A szenzorod nem tudja előre, mikor fogod lekérdezni, lehet olyan kiépítés, ahol önmagában gyűjtögeti az adatokat (persze egy helyi MCU-val kiegészítve), és amikor valaki megszólítja, akkor küldi el a gyűjtést.

Értem, köszi. Akkor lesz RTC is.

Sakk-matt,
KaTT :)

És mi van, ha boot után nincs hálózatod, nincs NTP szinkron? Ilyen eszközökbe kell az RTC, hogy legalább hozzávetőlegesen, néhány másodperc hibával tudják az időt, aztán majd be lesz állítva, ha lesz NTP.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Mivel a boot csak NFS-en lesz, így lesz hálózat, és aminek küldi az adatokat gép, RPI, az lesz az NTP szerver, tehát ha az nem megy, akkor hiába megy ez a gép, mert nincs hova küldeni az adatot. Rakok RTC-t az összes RPI-be, csak mert ennyien mondjátok, biztos nem véletlenül.
Köszi.

Sakk-matt,
KaTT :)

szerintem az nfs bugzik, ha nincs pontos ido.

Ha nfs boot van, akkor van ido, akkor halo nelkul nincs elet (tap), igy adatgyujtes se.

Itt mar annyian mondtak annyit, hogy az ido vegezeteig hezitalgathatsz.
Szerintem vagj bele.
Amint konkret hibaba futsz akkor tedd fel a kerdesedet valami angol oldalon, mert itt tuti nem talalsz embert. Ide csak hencegni vagy sirankozni jarnak (en is)...:)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Ennyire nem látom rossznak a HUP-ot. Ha konkrét a kérdés, arra érkezik segítség. Homályos megfogalmazásra nyilván trollkodás lesz a válasz.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"Amint konkret hibaba futsz akkor tedd fel a kerdesedet valami angol oldalon, mert itt tuti nem talalsz embert. Ide csak hencegni vagy sirankozni jarnak"

Azért nem ilyen rossz a helyzet.
Ha izgalmasabb, értelmesebb kérdést tennék fel, biztos több és komolyabb válasz jönne.
Szerintem itt segítőkészek az emberek, te is sokat segítettél, csak mindenki a maga módján az. Ha már azt megteszi, hogy lehülyéz, az is segítség... :)

Sakk-matt,
KaTT :)

A CAN address space (aka header) és a buszon elhelyezhető eszközök száma nem függ össze.
Picit másképp használják a headert és sokkal kevesebb eszközt helyezhetsz el a buszon, mint amennyiről írtál.
A start és ring topológia csak FT CAN-nél lehetséges, a mezei CAN az busz.
Továbbá a CAN egy multimaster busz, így a mindsensor-os rajzok kicsit... hogy is mondjam? Hogy a busz mindkét végét terminálni kell már nem is érdemes megjegyezni.
A becsatolt CAN splitter meg jó eséllyel a nyákon bus és a CAN stub hosszakkal játszik, ami csatlakozásonként 30cm. (Csak mert táp nem megy az elemre, így nem lesz az aktív eszköz.)
A szabványt kéne átnézni...

"Picit másképp használják a headert és sokkal kevesebb eszközt helyezhetsz el a buszon, mint amennyiről írtál."

De azért 30 eszköz csak megoldható összesen 1-4 CAN buszon.

"A start és ring topológia csak FT CAN-nél lehetséges, a mezei CAN az busz."
FT itt a fault tolerant?

"Hogy a busz mindkét végét terminálni kell már nem is érdemes megjegyezni."

Hát... nekem még a "minden vicc új" szinten vagyok a témában, és biztosan másnak is hasznos összegyűjteni a triviális, de fontos infókat :)

Én feltételeztem, hogy aki egy szabványhoz hardvert épít, az ismeri azt, és működni fog az eszköze a szabvánnyal.

https://i.imgur.com/jdicmsY.jpg

http://wiki.seeedstudio.com/CAN-BUS_Shield_V2.0/

Ez mennyire lehet ide hasznos?

https://www.avire-global.com/products/emergency-telephones/dcp-accessories/can-bus-splitter/

Ez sem jobb CAN busz splitter?

További PI HAT:

https://www.omzlo.com/articles/a-raspberry-pi-can-bus-hat-for-the-omzlo-iot-platform

RS485 CAN HAT for Raspberry Pi
https://www.waveshare.com/rs485-can-hat.htm

USB TO RS232 / RS485 / TTL Industrial Isolated Converter
https://www.waveshare.com/usb-to-rs232-485-ttl.htm

Angol írás:
How to Connect Raspberry Pi to CAN Bus
http://youness.net/raspberry-pi/raspberry-pi-can-bus

"
1.1.2 CAN Node
CAN Bus needs at least two nodes to make the network “up”.
So testing with one node will not work: this is the mistake n°1: Never use only one CAN Bus node.

1.1.3 CAN Termination
CAN Bus needs termination resistors between CAN-H and CAN-L at each end.
Mainly to avoid signal reflections. ISO 11898 recommends the value R=120Ω.
And that’s the mistake n°2: Without termination your CAN Bus will not work correctly.
"

CAN BUS Analyzer Tool hardware:

https://www.microchip.com/Developmenttools/ProductDetails/APGDT002

Cananka HAT
https://www.medo64.com/cananka/hat/

https://i.imgur.com/Bmh75gt.jpg

Features include:
* Up to 1 Mbit/s bus speed (125 kbit/s default)
* Fully isolated (1 kV)
* Does not require CAN bus power supply (onboard DC-to-DC converter)
* Supports powering Raspberry Pi from CAN bus (up to 24 V, 2 A)

Ez az utóbbi megoldás lehet, hogy akár 24V-on menjen a CAN busz és az RPI kezelje? (Az más kérdés, hogy mit érek el vele, és mi lesz a 3-5VDC SPI szenzorokkal :)

Sakk-matt,
KaTT :)

"Hogy a busz mindkét végét terminálni kell már nem is érdemes megjegyezni."

Hát... nekem még a "minden vicc új" szinten vagyok a témában, és biztosan másnak is hasznos összegyűjteni a triviális, de fontos infókat :)

FONTOS: MINDEN busz végeit terminálni kell, (ahogy lejjebb te magad is idézed:)

1.1.3 CAN Termination
CAN Bus needs termination resistors between CAN-H and CAN-L at each end.
Mainly to avoid signal reflections. ISO 11898 recommends the value R=120Ω.
And that’s the mistake n°2: Without termination your CAN Bus will not work correctly."

Aztán persze van, hogy maga az illesztő chip elintézi a terminálást... De attól még a reflexiók létezéséről nem árt tudni.

Én feltételeztem, hogy aki egy szabványhoz hardvert épít, az ismeri azt, és működni fog az eszköze a szabvánnyal.

És ha a szabványnak vannak módosulatai, akkor nem mindegy, hogy melyik gyártó melyik alszabványt valósította meg.

Persze ez azért csak akkor nem marhaság, ha a szenzorokat - néhány percenként - iszonytatós sebességgel szeretnéd leolvasni. Azt meg nevezzük csak tervezési hibának. ;)

Számszerűsítve - pl. egy lezáratlan i2c busz esetén:
- legyen a kábel kapacitása 60pF/m
- 20m kábel kapacitása 1200pF
- a felhúzó ellenállás 2kOhm
- az időállandó 1200*2000=2,4us
- a kábel késleltetése 6ns/m
- a késleltetés 120ns
Mivel a 2*késleltetés << időállandó, ezért nem lesz visszaverődés. Tehát nem kell lezárni a buszt.

Ismeretterjesztő jellegű magyarázat: A visszaverődő jel azért nem verődik vissza, mert mire odaér a kábel végére, annak a kapacitása még fel sem töltődött. Azaz még oda se ért. ;)

Van még egy probléma. A kábel végén a kelleténél alacsonyabb lesz a slew rate. Ezt viszont a buszmeghajtó regenerálja. Így a szenzor felé kellően meredek lesz a jel.

A dolog fordítva is igaz. Lehet kapni olyan meghajtókat, amik csökkentett slew rate-tel rendelkeznek, vagy lehet kis értékü soros ellenállásokat is alkalmazni. Ezek a trükkök csökkentik a zavarérzékenységet illetve a zavarok termelését is.

Persze a kábelt érdemes lezárni, ha a maximális átviteli sebesség a cél, de itt nem.
Hasonló az USB 2.0 kábel. Az illesztetlen lezárás miatt a kábellhosszt limitálják.

Nem tartasz attól, hogy esetleg én is elolvasom a hozzászólásodat? Szépen leírtad, hogy felfutó élnél nem lesz reflexió. Jó, és mi van lefutó élnél, amikor már nem a felhúzó ellenállással, hanem a vonalat lerántó félvezető belső ellenállásának és a felhúzó ellenállásnak a párhuzamos eredőjével kell számolni? ;)

Ez egy kicsit zavaros:

A visszaverődő jel azért nem verődik vissza, mert mire odaér a kábel végére, annak a kapacitása még fel sem töltődött. Azaz még oda se ért.

Most akkor odaért, vagy nem? Nem inkább arról van szó, hogy a kábel hossza lényegesen kisebb, mint az adott hullámimpedanciájú kábelen kialakult hullámhossz negyede?


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Konkrétan nem tartottam attól, hogy elolvasod. Ilyenkor meg az szokott jönni, amikor kikéred a személyeskedést, DE nem olvasol el semilyen adatlapot vagy szakirodalmat. Ez idegesíthetne, de inkább évezem, amikor fél bit információból azonnal kikövetkezteted, miszerint én vagyok a hülye. Pedig másik topicban már írtam: Én a rénszarvi vagyok. :-D

A visszaverődő jel azért nem verődik vissza, mert mire odaér a kábel végére, annak a kapacitása még fel sem töltődött. Azaz még oda se ért.

Magyarázom: A slew rate nagyon alacsony, ezért a terjedési idő lényegtelen. Ez egy ismeretterjesztő jellegű magyarázatnak megfelel. ;)

Ha olyan kíváncsi vagy a lefutó élre, akkor a PCA9600 adatlappal kell kezdeni. Alapesetben lehet reflexió, de ezt az áramkör beépített diódái az esetek többségében kivédik. Komolyabb meghajtásnál szükséges lehet külső dióda és csillapító tag alkalmazására is. Tekintettel a brutális mennyiségű adatfolyamra ;), itt nem kell ezzel foglalkozni. Sokkal egyszerűbb a slew rate (és az órajel) olyan mértékű korlátozása, hogy csökkenjen a zavar és a visszaverődés.
Szó sincs "a vonalat lerántó félvezetőről", mert a buszmeghajtó a primer oldal slew rate értékét "transzformálja" a nagyobb kapacitású terhelés felé. (Lásd még: PIC - SLRCON regiszter.)

A slew rate csökkentésről pl. Edge rate control for i2c bus applications (US20090066381A1) szabadalmi leírásban is olvashatsz. Hasonló megoldást tartalmaz pl. a PCA9509P áramkör is.

A slew rate csökkentése még lezárt vezetéknél sem rossz ötlet. Ezért használok a népszerű max485 helyett max483-at.

A félreértéseket általában az okozza, hogy az i2c eszközök időzítései általában a maximális névleges órajelhez vannak megadva. Pedig az i2c órajele DC...

Piszkálódást hagyjuk, nekem csak az nem tetszett, hogy levezettél valamit, ami féligazság. Épp a felfutó élre tettél állítást, ami nyilván alacsonyab slew rate lesz.

Jó, hogy írod a PIC slew rate kontrollját! Minap néztem katalóguslapot, csökkentett slew rate esetén 15 ns volt a fel- és lefutás tipikus értéke talán 5 V tápfeszültség mellett! Gondoltam, ez aztán nagy segítség. :( Elhiszem, hogy slew rate kontroll nélkül 3-5 ns körül is lehet a fel- és lefutás, de az a 15 ns még mindig irdatlan gyors. Másfelől értem azt is, hogy egy 32 MHz-ről járó PIC esetében a nagyon lassú jelváltozási sebesség azt okozná, hogy el sem éri a port lába a kívánt értéket, már indul is vissza adott esetben.

Az I2C-nek vannak szabványos sebességei, jellemzően 100 kHz, 400 kHz, 1.7 MHz, 3.4 MHz, ha jól emlékszem. Viszont másfelől kutyát nem érdekli, hiszen szinkron busz, amelyen ráadásul a slave felől a clock stretching is megengedett. Lényegében te is erről beszélsz, ez nem vitás kérdés közöttünk. :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

No, megjavítottam a fostalicska kínai szkópom tápját...

Elnézést, félrevezettelek!
Az i2c falling edge control nem az SLRCON, hanem az SSPSTAT:SMP. (18f24k50)
Ha az értéke default 0, akkor
12,4/22,2ns
ha 1, akkor
154/163ns
10kOhm felhúzó és 30/300pF terhelés mellett.

Az SLRCON függvényében - egy pickit3 terheléssel ;) - 38,4/38,4 és 28,4/16,8ns volt a fel- és lefutási idő. Ez tényleg nem sok. A szkóp triggereléséhez 10-20 utasítás hosszú jel kell 48MHz-en.

Igen, ez jogos.

Tudtok ajánlani olyan adaptert / splittert / hubot, ami megoldás arra, hogy csillagpontosan tudjam bekötni a CAN busz node-okat, 20-30 méterre? Ahogy írtátok: aktív splitter / hub kellene? Az összes splitter esetén amit találtam, egyikbe sem kellett extra power, ha jól emlékszem.

A CAN busz - Ethernet adapter megoldás lehet erre?
Erről lentebb csinálok egy nagyobb írást, amiket találtam.

Sakk-matt,
KaTT :)

Gondolom van egy elkepzelesed, hogy miert igy szeretned, csak egy felvetes: ha 20+ eszkozrol van szo, es tobb helyisegrol, nem lenne celszerubb valami radios osszekottetes? Nekem jelenleg 16 szenzor megy (homerseklet + paratartalom (meg az elem feszultsege, meg jelerosseg)), 10+ helyisegben, 3 szinten, 434MHz-en, es tok jol mukodik. Szamitasaim szerint kb. 1 evet birnak az szenzorok 1db CR2032-rol (percenkent kuldenek adatokat). Es nem kell vezetekezni.

Van egy gateway, ami ESP8266 alapu, MQTT-n tolja kifele a szenzorok adatait, onnantol pedig a lehetosegek szinte korlatlanok.

/sza2

--
Digital? Every idiot can count to one - Bob Widlar

hm, ez szimpatikus, lehet tudni többet a konkrét hardverekről? köszi!
--
Gábriel Ákos

+1
--

Korabbrol: https://hup.hu/node/161837#comment-2289280

Azota annyit valtozott a rendszer, hogy a kepen lathato sajat board nem csak a szenzorokhoz van, hanem a kozponti egyseg ossze van kotve egy ESP8266-tal, ami szorja az osszes szenzor altal mert adatot MQTT-n (van egy mysql adatbazis, ami toltodik az adatokkal), nezegeteshez irtam egy egy js+php minimal design cuccot ami grafikusan megjeleniti az ertekeket rateve az szintek alaprajzara, de megy egy grafana is, illetve beleraktam home-assistantba is.

A radio board nekem keszen van (all rendelkezesre a szukseges mennyisegben), szoval azzal sok dolgom nem volt - megvenni draga, de megcsinalni sem olcsobb szerintem (4 retegu NYAK, stb.). De a munkatarsaimmal azon gondolkodunk hogy kellene csinalni egy ket retegu NYAK-on kialakitott verziot is (IPD illesztovel, minimalizalva a kulso alkatreszek szamat - igaz, kicsit gyengebb kimeno teljesitmeny es valamivel rosszabb erzekenyseg lenne az ara), ami mar arban sem lenne veszes.

Egy Zigbee-hez hasonlo stack fut az eszkozokon, van egy koordinator amihez csatlakoznak a szenzorok (sleepy end device-ok). PHY: 434MHz, 2GFSK, talan 250kbps bitrate. A szenzorok: Si7021. A kijelzot raterveztem ugyan, de a nagy reszere a boardoknak nem tettem ra mert felesleges.

/sza2

--
Digital? Every idiot can count to one - Bob Widlar

Wow, gratulálok, szép munka, hogy így elkészült. Itt a HUP-on jó sok szakember, azaz varázsló van! :) Jó látni, hogy komplett megoldások készülnek el az egyedi igényeknek megfelelően.
Egyre inkább látom, hogy a kábelezésen történő kommunikáció milyen kihívásokat rejt.
Kezdem még jobban tisztelni ezt a szakmát, szakirányt.
Pozitívan látom a helyzetem, mert egész mélyről kell emelkednem, tanulnom, így sokat tudok fejlődni. Lehet, hogy tetováltatok magamra egy 100 Ohmos ellenállást... :)

Sakk-matt,
KaTT :)

"nem lenne celszerubb valami radios osszekottetes"

Már kész a kábelezés, és elvből nem szeretnék rádiós összeköttetést a szenzorokhoz.
Biztosan tökéletesen tud működni rádiósan is, nem vitatom. Sőt, én is láttam már több ilyet élőben. Működik.

Köszönöm azért a lehetőséget és javaslatot. WiFis eszközökből töredék idő alatt meg lehetne ezt csinálni, főként kész IoT eszközökből, lásd Xiaomi, Belkin, Philips, ... megoldásai, és még kb minden komolyabb gyártó próbálkozik kicsípni egy szeletet ebből a nagyon növekvő piacból.

Sakk-matt,
KaTT :)

Mivel ez a szakmám, néha elfog a hevület, hogy csináljak valami mikrokontrolleres akármit. Aztán mindig lekonyul a lelkesedésem, mert arra jövök rá, hogy semmi szükségem egy akármire. Pedig megvan hozzá a fejlesztői környezetem, a tudásom, csak mindig arra lyukadok ki, hogy minek.

Más megközelítésben azt szeretném kérdezni, ez a rakás páratartalom és hőmérsékleti adat mennyiben járul hozzá a személyes boldogságodhoz, miben teszi könnyebbé az életedet?

Amúgy egyszer illesztettem USB-re I2C-n keresztül hőmérőt (MCP9808). Az USB stack-et készen használtam fel, a kód többi részét én írtam assembly-ben. A desktop gépembe van dugva, logolja a hőmérsékletet. Évek óta nem néztem meg még azt sem, mekkora a logfile, nem rajzoltam belőle időfüggvényt. Ha a router-embe dugnám, esetleg tűzjelzőt lehetne belőle csinálni. Talán.

Szóval ezek olyan sok hűhó semmiért.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Mondjuk annyi ertelme van, hogy a homersekleteket merve (nalam pl. minden helyisegben), meg lehet oldani a homerseklet szabalyozasat (radiatorok eseten a radiatorszelepekkel, padlofutes eseten az oszto-gyujtobe kotott szelepekkel).

Valoszinuleg lehetne fejleszteni olyan algoritmusokat amik a komforterzetet es a gazdasagossagot figyelembe veszik, es kihoznak belole valami optimalis futesi megoldast - erre meg nem volt idom, lehet, hogy nem is lesz.

Ami a paratartalmat illeti, a tenyleg csak a "jo tudni" kategoria (lehetne ugyan a mert ertek alapjan parasitani (netan paratlanitatni), de azt nem tervezem), viszont mivel a szenzor homerseketet es paratartalmat is mer, miert ne hasznalnam fel azt az erteket is?

Raadasul idoben sem vitt el rengeteget, mert a munkahelyi projekttel volt kb. 90% atfedes.

Szoval en egyaltalan nem tartom ertelmetlennek.

/sza2

--
Digital? Every idiot can count to one - Bob Widlar

Nem leszólni akarlak, én is örülök minden bigyónak, ami van, nemrég vettem rádió távirányítással kapcsolható konnektort, kényelmes az ágyból be- vagy kikapcsolni az álló ventilátort.

Azért ezzel a „jó tudni” dologgal úgy vagyok, hogy nekem sem a libidóm nem lesz nagyobb attól, hogy ha leolvashatom, hogy bizony, a relatív páratartalom most éppen 83.4215377 %, sem a fizetésem nem lesz ettől több, a torokfájásom sem múlt el még ilyesmitől, és a kaja sem lesz finomabb és olcsóbb az étteremben ezektől. Hazamegyek, ablakot nyitok, szellőztetek, mindezt vakmerően műszerek leolvasása nélkül, érzésből. :)

Néha azon tűnődöm, hogy nem lesz boldogabb az ember attól, hogy újabb és újabb tárggyal veszi magát körül. Az emberi kapcsolatok, a másikra való odafigyelés, a pajzánkodás sokkal fontosabbak. Bár van, amikor van egy határozott funkció, cél, akkor azt meg kell valósítani. De sokszor azt érzem, az eszközhöz próbálunk célt keresni, holott a feladat megoldásához kellene eszközt választani.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"Néha azon tűnődöm, hogy nem lesz boldogabb az ember attól, hogy újabb és újabb tárggyal veszi magát körül. Az emberi kapcsolatok, a másikra való odafigyelés, a pajzánkodás sokkal fontosabbak."

Igen, ha automatikusan meg van oldva a fűtés / hűtés kezelés, párátlanítás, akkor több idő van... pajzánkodásra! :)

"Bár van, amikor van egy határozott funkció, cél, akkor azt meg kell valósítani. De sokszor azt érzem, az eszközhöz próbálunk célt keresni, holott a feladat megoldásához kellene eszközt választani."

Különbözőek vagyunk. Van aki napi sok órát focit néz és tudja visszamenőleg az összes mérkőzés eredményét és játékos igazolását. Van aki pedig helyette próbál szenzorokat hálózatba kötve otthonvezérlést csinálni. Csak mert valakinek szórakoztatóbb, mint a focistákat nézni, ahogy egy bőrdarabot kergetnek, aztán ha végre megszerzik, azonnal elrúgják. :-)

Mivel neked a munkád is ilyenhez kapcsolódik ha jól értettem, nyilván nem akarsz azzal foglalkozni, ami a munkád munkaidőn túl is.

Sakk-matt,
KaTT :)

"Igen, ha automatikusan meg van oldva a fűtés / hűtés kezelés, párátlanítás, akkor több idő van"
Szóval nemcsak nézni akarod a szenzorokat, hanem a fűtés-hűtés folyamatába is be akarsz avatkozni :(
Pedig szerintem ahhoz a szakmához sem értesz.

Ez egy nagyon nehéz kérdés, ki mennyire ért a szakmájához. Építkezés előtt sok építésszel, gépésszel beszéltünk. Egyik gépész éppen akkor tette tele a tetejét kollektorral. Megkérdeztük, mit fog csinálni nyáron a sok meleg vízzel. Válasz: még nem tudja.

Nálam is automatizált sok minden, helységenként van termosztát, nagyon jó dolog. Ez az automatizálás kinek a szakmája egyébként? Gépészé? Villamosmérnöké? Informatikusé? Nálunk végül én "lőttem össze" (informatikus) a rendszert, teljesen jól működik. Szerintem ez egy viszonylag új terület nem ipari (azaz lakossági) környezetek esetén. Olyan, mint mikor a szoftver fejlesztő és az üzleti résztvevők közé kell egy tolmács. Itt a szoftverfejlesztőt gépészeti tudással kell összekötni. Egy ház esetén nem rentábilis, de ha kiforrja magát, nem lesz ez annyira bonyolult megfelelő absztrakció esetén. (az más kérdés, hogy miként fogja kiforrni magát, mert az ipar mostanában a "gyorsan tudjuk le a feladatot primitív módon" irányba halad).

Nekem az az érzésem, igényt próbálnak generálni olyan dologra, amire semmi szükség. Nem igazán értem, mi a pláne abban, hogy minden egyes világítótestet mikrokontroller vezéreljen.

Ami pedig a fűtés szabályzását illeti, ott nem árt szabályozástechnikai fogalmakkal tisztában lenni. Mitől nem fog a szabályzás oszcillálni? Van-e elegendő fázistartalék benne? Egy PID-szabályozónak milyenek legyenek az együtthatói? Milyen a szabályozandó entitás dinamikus viselkedése? Mi annak az átviteli függvénye? Hány tárolós tag, holtidős-e, koncentrált paraméterekkel leírhatjuk-e, és így tovább.

Jó, tudom, van egyszerű megoldás: csináljunk egy vacak állásos szabályozót kis hiszterézissel, a holtidők miatt meg majd szép nagy lengésekkel teszi a dolgát, így néha melegünk van, néha picit fázunk.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Látod, mennyivel rosszabb neked, hogy tudod miről van szó?
Ő megcsinálta valahogyan, és élvezi, hogy működik.

(Mondom én, hogy itt hamarosan a szofferesek vakbélműtétet is vállalnak. Csak szike kell hozzá, meg csipesz.)

Ez is gond: a kütyü buzerátorok hajlamosak túl magas lóra ülni, közben olyan genyákat is tudnak gyártani, hogy katasztrófa.

Magad is leírod, hogy "valahogyan", azaz halvány gőzöd sincs az egészről, de azért van egy határozott véleményed.

Világítás: mondjuk azért, mert vannak helyzetek, amikor vezetékeléssel nem, vagy csak bonyolultan tudod megoldani. Például a kertben levő lámpát bentről is szeretnéd kapcsolni. Hosszan lehet sorolni, de hozzáállásodban erős maradiságot érzek: ha eddig megvoltunk nélküli, miért ne lennénk meg ezután is? Ekkora erővel még a barlangban csiholnánk a tüzet, paráználkodni ott is lehetett, ráadásul melegített is a tűz kialvása után.

Fűtés szabályozása: honnan tudod, hogy nem vagyok vele tisztában? Egyfelől informatikai karon volt szabályozástechnika, bár sok konkrét emlékem nincsen, ez igaz. Másfelől a fejlődés pont oda vezet, hogy nem kell minden vacakhoz teljes mélységében érteni, mert vannak építő elemek. Egyszerűsítve vannak szoftveres termosztátok, aminek van egy aktuális hőmérséklet bemenete, néhány paramétere (elérni kíván hőmérséklet és működési jellemzők), ezenkívül van egy kimenete, amivel nyitni/zárni tudod a szelepeket. A szoftver modul megoldja neked a szabályozást, neked annyi a dolgod, hogy tud, melyik működési módot válaszd ki és miként paraméterezd. Jobban nem is érdekel. Viszont most már több télen is remekül működött, annyi teendőm van minden össze, hogy meg kell nyomnom egy gombot a fűtési rendszer aktiválásához. A hőmérséklet egyenletes, nincs kilengés.

A gond ott van, hogy egy normális rendszer felépítése se nem gépész, se nem villamosmérnök, se nem műszerész feladat, hanem inkább informatikai. Viszont az informatikusoknak manapság egyre inkább a Wifi a legalacsonyabb réteg. Ez messze nem optimális rendszerhez vezet, mert ezzel a tendenciával minden fűtési szelepnek is dedikált IP címe lesz 5G kapcsolattal.
Anno az egyetemen voltak informatikai feladatok (már nem is emlékszem a nevükre), ahol néha villamosmérnökök is indultak. Okos srácok voltak, nem tagadom, de nagyon sok esetben a szoftver kb olyan volt, mintha kovács vett volna a kezébe egy nyomtatott áramkört. Ennek azóta is folyamatosan látom sokféle megnyilvánulását.

A területek integrációját nem lehet megkerülni, csak sajnos kevés a normális összekötő elem: egyik túl alacsony szintű, másik túl magas. Vannak próbálkozások, de munkás sajnos.

"A gond ott van, hogy egy normális rendszer felépítése se nem gépész, se nem villamosmérnök, se nem műszerész feladat, hanem inkább informatikai. Viszont az informatikusoknak manapság egyre inkább a Wifi a legalacsonyabb réteg. Ez messze nem optimális rendszerhez vezet, mert ezzel a tendenciával minden fűtési szelepnek is dedikált IP címe lesz 5G kapcsolattal."

Igen, ismerős, és az ilyen "informatikusok" programoznak is... különböző "varázslókkal", netről letöltött nem a célra megfelelő kóddal, amit módosítanak fapadosan és egy nagyon nagy, lassú kóddal próbálják megközelíteni a célt.
Ahogy vannak gyorstalpaló programozó sulik, neveket inkább nem írok, ahol pár hónap alatt "szenior programozókat" képeznek, aki 1 feladatot meg tud csinálni, mást pedig még nem látott.

Azért írom le, mert ebből a szempontból engem is lehet hozzájuk hasonlítani: én is pár hónap ráfordítás után próbálok szenior szintű feladatokat megoldani - a segítségetekkel, iránymutatásotokkal, és nagyon sok óra szakmai anyag olvasás után. Az a különbség, hogy nekem nem a megélhetésem, nem másnak csinálom, hanem hobbiból, kihívásból. A végterméket én fogom használni. Magamnak készül, így nem zavar az overkill, a túl drága kivitelezés, esetleg a nem tökéletes forrasztás: maximum újra csinálom, vagy máshogy csinálom.

Tehát engem lehet hasonlítgatni, ami nem kérdés, hogy jogos, csak nézzük meg a célt is, hogy micsoda, és hogy a cél ismeretében mennyire elfogadható, hogy valaki egy új területen akar gyorsan eredményt elérni - a saját szórakoztatására és kényelmére, ami vagy sikerül, vagy nem.

Sakk-matt,
KaTT :)

Egyetemi és hobbi szinten semmi gond nincs azzal, ha valaki mással is próbálkozik, sőt általában ez hozza a fejlődést. Ha valakit érdekel, akkor elmélyül benne, megtanulja, fejleszti. Arról nem beszélve, hogy nincs olyan szakma, amit maximumon lehetne űzni, mindig van fejlődési lehetőség (ezáltal minden tudás/tapasztalat viszonylagos). Eddig a legrosszabb idegen vezetőnk egyike az volt, aki büszke volt arra, hogy milyen régóta űzi a szakmát, az egyik legjobb pedig egy biztonsági őr.

A gond ott van, amikor a tákolmányok ipari méreteket öltenek. Ma például azzal szembesültem, hogy egy orvosi műszerben egy "report" (két kép és némi felirat), amit A4-es oldalra kell nyomtatni nem más, mint egy 140KB-os JPG fájl közepes minőséggel tömörítve, 1760x1240-es felbontással. Igen, úgy is néz ki. Igen, jó drága volt.
Nyilván mindenki tévedhet/hibázhat (sajnos én sem vagyok kivétel), de a fenti esetet például nem tudom megérteni. Senkinek nem tűnt fel, hogy szőrösek a betűk, zajos a betűk körül a kép?

Igen, én el sem kezdem sorolni, amikor egy drága szoftver katasztrofálisan működik vagy óriási erőforrást igényel a rosszul választott programnyelv vagy rossz megvalósítás miatt. Én ismerek pár igazi rossz fejlesztőt, de el kell mondjam, hogy a többségében jó szándékkal van övezve a tevékenységük: ők a saját szintjükön a legjobb szándékkal csinálnak rosszat. Nem tudják / akarják felmérni a saját gyengeségeiket, esetleg rossz következtetésekre építenek fel logikákat, majd azokat használják. Van aki félelemből nem ismeri be, hogy valamit nem tud, aztán téves dolgokat készít. Persze vannak a nagy arc, beképzelt fejlesztők, akik azt hiszik, hogy okosak és sok éves elavult tudásuk van, esetleg ők is pár ellenpélda miatt rosszul felépített logikában nagyon biztosak és ezt szajkózzák. Ha jól következtetnek, jó amit csinálnak, ha rosszul, akkor káros, és nem meggyőzhetőek a büszkeségük miatt. De ez csak pár ismerős működése, nyilván közel végtelen módon jók vagy rosszak az emberek, ha a programozási tudásukat kell nézni.

Én meggyőzhető vagyok érvekkel és elismerem ha megértem, hogy tévedtem. Van sok olyan elképzelésem / vágyam / célom, ami nyilvánvalóan nem egyezik másnak az igényével / ízlésével, de ez más kérdés. Mint ahogy a legszebb szín is egyedi, mindenkinek más lehet.

Sakk-matt,
KaTT :)

+1
Az első félre.

A saját célra prütykölés az más. Sokkal kínosabb, amikor az ügyfélnek mondom, hogy ne mondjon marhaságokat ... majd dicső szoftveresünk kinyögi: Éppen most programozza - a héten elkészül vele -, amit két éve specifikáltam. Konkrétan: Egy számról meg kell állapítani, hogy másik két szám közé esik-e. No comment.

Egy számról meg kell állapítani, hogy másik két szám közé esik-e.

Azért ez nem nyilvánvaló. Ha megmondod két komplex szám közül, melyik a nagyobb, akkor ügyes vagy. :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Pedig van rá szabály.

Szerintem komplex számokra nincs értelmezve a kisebb és nagyobb operátor, mert nem lehet értelmezni. Csak az egyenlő és nem egyenlő értelmezhető. Nyilván az abszolút értékekre már lehet mondani, hogy kisebb vagy nagyobb, de az már valós szám.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"Szóval nemcsak nézni akarod a szenzorokat, hanem a fűtés-hűtés folyamatába is be akarsz avatkozni :(
Pedig szerintem ahhoz a szakmához sem értesz."

Persze hogy nem értek a hűtés-fűtés folyamat vezérléshez sem. Nem az a szakmám.
Ahogy a hardver tervezés és hardveres összeépítés sem, ez mind csak hobbi.

Ha biztonságosan, ellenőrzötten jól működik a hőmérő / páratartalom (másik fajta mérővel is néztem), akkor egy idő után olyan komoly algoritmusokat fogok írni, hogy:

Ha a hőfok elérte a 30 fokot, és engedélyezve van, hogy bekapcsolható a légkondi a helyiségben, és nincs kikapcsolva az automatizálás és nincs nyitva az ablak, akkor:
légkondi bekapcsolás, majd percenként ellenőrzés, hogy hány fok van. Ha elérte a hőmérő a 25 fokot, akkor légkondi kikapcsolás.
Ha eltelt 10 perc és nem változott a hőmérséklet: SMS/EMAIL nekem, hogy nem működik valami.

Ugyanígy a fűtéssel: ha engedélyezett a fűtés bekapcsolás és engedélyezett az automatizált hőmérséklet szabályozás és nincs nyitva az ablak, akkor ha 20 fok alá esik a hőmérséklet, fűtés bekapcsolás, ha elérte a 25 fokot, fűtés kikapcsolás. Ha nem változik a hőmérséklet felfelé x percig, akkor SMS/EMAIL értesítés nekem.

Persze ha majd ott leszek, ennél átgondoltabb lesz, ez az első körös ötletem.

Szobánként kikapcsolható/bekapcsolható a hűtés és fűtés vezérlés.
Ezen felül központilag ki és bekapcsolható az automatizált fűtés és hűtés vezérlés.
Nyilván eleinte ott leszek a szobában és nézni fogom, hogy bekapcsolja-e és lekapcsolja-e, nézem majd a log-okat, stb.
Később kitalálok további szintű biztonsági dolgokat, vagy hogy kapcsolható legyen a fűtés bekapcsolás, ha nyitva az ablak, stb.

Ezen kívül nem értem, hogy miért szomorít el téged, ha valaki a saját lakásában kísérletezik. Csak nem velem laksz? Kezdek gyanakodni... :-)
Gondolom az is zavar, ha valaki vezetés közben mobilozik, mert veszélyezteti magát és a környezetét. Továbbá remélem felügyelsz minden lakásfelújítást, nehogy bármit is illegálisan módosítsanak, mint amire engedélyük van. :-)

Hívhatlak "hardvertervező-valamint-automatizált-hűtés-és-fűtésvezérlő-ellenőr szuperhősnek"? :-) Hiszen ki más aggódna ilyenért?

Sakk-matt,
KaTT :)

> Pedig szerintem ahhoz a szakmához sem értesz.

Ez ugy hulyeseg, ahogy van. Az ember ahhoz ert amit megtanul. A papir max megnyugtat.

Nem hinnem, hogy a szemelyeskedes eloremozditana a tanulas folyamatat.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

"Pedig megvan hozzá a fejlesztői környezetem, a tudásom, csak mindig arra lyukadok ki, hogy minek."

Így van, ne csináljad, ha nem látod értelmét. Én sem csinálnám, ha nem lenne értelme az én szemszögemből.

"Más megközelítésben azt szeretném kérdezni, ez a rakás páratartalom és hőmérsékleti adat mennyiben járul hozzá a személyes boldogságodhoz, miben teszi könnyebbé az életedet?"

Jelentősen! Főleg a BME680-ban lévő levegőminőség ami hasznos, mert tényleg ha nagyon alacsony, akkor szellőztetni kell.
Továbbá ha a páratartalom elér egy magas értéket, akkor be tud kapcsolni a légkondi a párátlanító üzemmóddal (IR-en indítom).

Ha nem lenne hasznos számomra a hőmérséklet, páratartalom, levegőminőség, akkor az egészet nem csinálnám. Tudok kapcsolni hozzá hűtést, fűtést, párátlanítást.

"Szóval ezek olyan sok hűhó semmiért."

Igen, neked az. Nekem pedig az életet megkönnyítő eszközök. Különbözőek vagyunk, mások az igényeink és céljaink.
Továbbá nekem ez az egész egyben hobbi és kihívás is, hogy meg tudom-e csinálni, azon kívül, hogy hasznosnak gondolom.
Ha majd x éve használom, lehet, hogy máshogy látom.

Sakk-matt,
KaTT :)

Nehogy félreérts, nem akarom letörni a lelkesedésed, s mindenképpen kreatív az ilyen elfoglaltság, a megszerzett tudás pedig használható a későbbiekben. Mindenképp jobb, mint munka után minden este kocsmában lopni a napot, pusztítani a májat meg az agyat.

Inkább egy picit az az érzésem, mint amikor középiskolás voltam, s egy osztálytársammal úgy éreztük, írni kellene valami programot BASIC-ben. Az első sor meg is született hamar:

10 CLS

Jó, de hogyan tovább? Egyáltalán mit csináljon ez a program? :) Kedvünk volt, csak valódi cél, feladat nem. Aztán persze írtam Z80 assembly-ben tetrist, illetve Z80 assemblert a hozzátartozó editorral együtt.

De most komolyan. Mit csináljon az ember? Az n+1. órát? Frekvenciamérőt? És akkor nézem majd, ha pakson néhány ezrelékkel lassabban forognak a generátorok? És addig nézem ezt, amíg belefáradok? Amúgy Z80 alapon csináltam frekvenciamérőt kb. 30 éve, a mai napig működik, de a multiméterem is mér frekvenciát. Hőmérséklet. Tök jó, bennevan a DCF77-re szinkronizálódó órámban, van egy a fűtés szabályozójában, van egy a desktop gépemen, aminek az USB illesztését csináltam meg, van egy folyadéktágulás elvén működő, hagyományos az ablakban, valamint egy lázmérő. Kell a fenének amúgy, azt úgyis érzem, ha fázom, vagy ha melegem van.

Ami valóban érdekelne, az sok pénz és idő, mechanikai kivitelezés, azon bukik el. Ami egyszerű, az meg nem kell, mert meg lehet venni készen, ráadásul a bedobozolása, a mechanika is megoldott.

Mondom, semmiképp sem venném el a lelkesedésed, csak ott tartok, hogy nekem is lenne kedvem valami mikrokontrolleres marhaságot csinálni, de mindig oda jutok, hogy semmi értelme.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Menj el egy life vagy business coach-hoz, szánjad rá az időt és pénzt, és segít célt találni! :)

Egy bölcs azt mondaná: ha semmi értelme számodra mikrokontrolleres marhaságot csinálni: ne csináld.

Én azért csinálom, mert látom az értelmét, hasznát, és még kihívás is van.

Ahogy a boldogság is belül van, és nem függ senkitől és semmitől sem, úgy én sem azért kergetem ezt a projektet, mert ettől bármi többet is várnék. Mint ahogy egy jó ételt sem azért főzők magamnak, mert ne tudnék olyat, vagy akár jobbat venni, hanem azért, mert én akarok elkészíteni, úgy, ahogy kedvem tartja, és lehet, pont olyan ételt senki nem készítene nekem, talán csak egy privát szakács. És zárásként: simán lehet, hogy az elkészült étel 10-ből csak 2-3 embernek ízlene rajtam kívül, én mégis erre vágytam. És megkaptam, teljesült, elégedett vagyok, nekem ez jó.

Mondhatnék én is példát, hogy valaki miért költ vizuális tuningra az autóján vagy motorján, hogy ezt átfesti ilyenre, vagy olyanra, esetleg felrak egy drága díszítést, aminek az én szemszögemből semmi értelme, stb. Mégis tömegesen csinálják ezt, mert mindenkinek más az iránya, célja.

Más ember cselekedetében nehéz sokszor meglátni a célt, értelmet, mert másképpen működik. A világban annyi hülyeséget csinálnak az emberek, bizonyos külső szemszögből nézve biztos az én cselekedetem is az, hogy miért szánok rá időt/energiát/pénzt erre.

Nem kell mindenben az értelmet keresni. :-)

Sakk-matt,
KaTT :)

Mondom, a motiváció bennem is ott van, tetszenek a mikrokontrollerek jópofa feature-jei, kedvem is van, mert jó érzés alkotni, s ahogy írod is, a legjobb az adott dolog egyedisége, az, hogy a készen megvett dolgokból mindig hiányzik valami az ízlésemhez képest, vagy nem úgy működik, ahogy szeretném.

Na jó, de mit csináljak? Számológépet, multimétert? Ha ez lenne munkában a feladatom, megcsinálnám. Így viszont csak előveszem a fiókból, és használom, ha kell. A perifériák felől érdemes megközelíteni. Output fény és hang lehet nagyjából, illetve fordulatszám, nyomaték, ha villamosgép hajtását csináljuk. Az input? Fényerő, hang, nyomás, fordulatszám, hőmérséklet, erő, sugárzás, pozíció. Persze lehet akár futásidő késés, például akusztikus távolságmérés, rezgőkör csillaptása kapcsán lehet fémkeresőt csinálni. Mondjuk abban szerintem tudnék nagyon jót csinálni, csak minek. Ott inkább az a korlát, hogy a tekercstől távolabbi tárgyak nem befolyásolják a mágneses teret, így egy szinten túl hiába minden erőlködés. Lehet jópofa delta-szigma A/D konvertert csinálni. Jó, és? Mondjuk elkészült, de mit csinálok egy teszem azt, 16 bites, O(2^n) A/D konverterrel? Előveszem majd az utcán, mutogatva, mint egy szatír a farkát, hogy nézd, nekem ilyenem van? :D


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Eddig is értettem, amit most írtál.
Nekem ahogy értelmezem, nincs ambíciód csinálni ilyesmit, de szaktudásod van hozzá. Nincs ezzel semmi baj.

Úgy látom, most a legnagyobb kedved fórumozni van... :-)

Lehet, tudat alatt valami titkos, misztikus megbízásra vágysz, amit még senki nem csinált, de képes vagy rá... Csak nem jött a megkeresés... még... Esetleg egy privát, fizetős munkát / másodállást / projektet kellene keresned, ahol ha nem is kedvtelésből, de pénzért használod a tudásod, és akkor lehet, elégedettebb lennél.

Vagy lehetne azt, hogy keresnél egy nagyon drága, költséges hobbit, elköltenél rá rövid idő alatt nagyon sok pénzt, majd segítségből felajánlanám, hogy csináljad meg az én összes hardverrel és kábelezéssel kapcsolatos teendőmet, mert azzal óriási pénzeket tudsz megtakarítani, ahhoz az új, költséges hobbihoz képest! Win-WIN! :-) :-) :-)

Talán a lelkiismereted előjött, hogy a jelenlegi szaktudásodat nem használod ki, viszont amikor célt keresel, nem találsz semmit. A komment utolsó bullsh1t része: Ne csak nézz, láss! :)

Sakk-matt,
KaTT :)

Itt alapvetően két dolog van. Műszeriparban fejlesztek, ott olyan feladatok adódnak, amit mindenképp meg kell csinálni, miközben egyáltalán nem kézenfekvő a megoldás. Mondhatnám, kifejezetten nehéz, bonyolult, hobby-ként biztosan nem csinál ilyesmit az ember. Ugyanakkor éppen azért érdekes, mert kihívás, így szeretem is csinálni. Ott inkább az a baj, hogy akármilyen utat választ az ember, mindenképp falakba, a megvalósíthatóság korlátaiba ütközik. Aztán, ha ehhez hozzátesszük, hogy gazdasági kritériumoknak is meg kell felelni, tovább romlik a helyzet.

A másik része az, hogy csinálnék szórakozásból valami olyasmit, ami viszonylag látványos, ha úgy tetszik, garantált pozitív eredménnyel kecsegtet. Nagyon van kedvem hozzá. Van itthon mikrokontrollerem többféle is, forrasztópákám, fejlesztői környezetem, egyéb alkatrészek, ha valami hiányzik, akkor meg kell venni. A gond inkább az, hogy kitaláljam, mi az a jópofa kvázi játékszer, ami hiányzik, aminek örülnék, ha megcsinálnám. Mert az, hogy megnyomok egy gombot, s kiír egy LED kijelzőre 1-től 6-ig egy véletlen egész számot, valljuk be, nem igazán motiváló. Lehet, hogy 13 évesen még az lenne, de most ennél azért valami értelmesebb dologra vágyom.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Én teljesen megértem KaTT kolléga hozzáállását.

A mi házunkban sok mindent automatizáltam és több olyan funkció is előjött, ami nagyon tetszik.

Az egyik a redőnyök kezelése. Elsőre primitív feladatnak tűnik. Mi a kihívás? Az első cél az volt, hogy napsütés esetén menjen le a redőny, de csak ott, ahol kell és csak addig, amíg kell (a házban világos legyen lehetőség szerint). Ehhez kell egy fénymérő, illetve tudni kell, mikor honnan süt a nap. A fénymérő adott, a mikor honnan süt a nap nehezebb kérdés. Most nagyon egyszerű a megvalósítás: napszak alapján határozom meg, de jobb lenne a tetőkilógását és a nap magasságát is figyelembe venni, de eddig még nem jutottam el. Lehet, hogy nem is fogok, legfeljebb ha valamikor nagyon unatkozom, mert sokat nem lehetne vele nyerni.
Két probléma van a redőnyök automatizálásával: nyáron korán kell a nap, az ember kézzel is szeretné működtetni. És túl bonyolult se legyen.
A rendszer jelenleg olyan, hogy minden redőnynek két állapota van: kézi és automata. Ha kézi, akkor nem mozog napszak és fény alapján, ha automata, akkor igen. Este, mikor sötét van, akkor kvázi nullára csökken a fényerő, ekkor lemennek a redőnyök és kézi üzemmódba váltanak. Emiatt korán reggel nem mennek fel. Az összes redőny reggel két módon tehető automatába: időzítéssel (kiváló ébresztőnek), vagy kézzel (telefonról vagy falon levő kapcsolóról). Ha valamelyik redőny kapcsolóját megnyomjuk, akkor automatából átvált kézibe, azaz nem fog önállóan mozogni (telefonon egyenként lehet állítani a redőnyök állapotát).
Nagyon szeretem ezt a rendszert, előző házunkban őrület volt a redőnyök kezelése.

Egy másik klassz megoldás a medence utántöltése. A cél az, hogy ne kelljen vele foglalkozni. Többször előfordult, hogy betettem a slagot utántölteni, de ott felejtettem. Egyszer annyira ott felejtettem, hogy 100e körüli kár keletkezett (+ az elfolyt víz, közel 24 órán át folyt). Viszont az automatika is elromolhat, ennek esélyét csökkenteni kell. Például ha úszókapcsoló figyeli a szintet és az beragad valami miatt, akkor szintén gond van.
Erre a megoldás az lett, hogy kvótája van a medencének: X perc töltés engedélyezett. Ha letelik az X percnyi töltés, akkor nem tölt tovább (akkor sem, ha azt érzékeli, hogy kellene) és kapok egy emailt. Van egy gomb a telefonon, amit ha megnyomok, akkor nullázom a perceket és mehet tovább a töltés. Nagyon bevált.
Ezenkívül ha megy a szűrő, akkor nem mérvadó a szintmérés. Azaz szintet csak akkor szabad nézni és tölteni, ha nem megy a szűrőrendszer.
A bónusz, hogy egy apró úszókapcsolóval meg tudtam oldani, mert pont annyi a hiszterézise, hogy jól működik így is.

És még jónéhány hasonló dolog van a házban és körül, ami valós problémát old meg. És ezek nem mű problémák: amíg nem voltak, sok időt, odafigyelést igényeltek (nem megfelelő árnyékolás esetén brutálisan fel tud melegedni a ház - de télen ez jó -, ami explicit érződik; medencénél hasonlóan károkat okoz a víz), amióta megvannak, azóta csak a hasznát élvezi az ember.

Köszönöm a gyakorlati példákat, a redőnyvezérlés nekem is a listán van, már úgy van kiépítve hogy vezérelhető relével és kézzel is.
Jó ötlet ez a kézi és automata mód közötti kapcsolás.
Annyira tetszik az ötlet, hogy eldöntöttem, hogy lesz valamilyen kijelzés, hogy a redőny milyen üzemmódban van, csak hát olyat szeretnék, ami lehetőleg csak állapotváltáskor fogyaszt áramot, és nem világít. Elsőre az e-papper / EINK jutott az eszembe:

https://www.thoughtsmakethings.com/Pimoroni-Inky-pHAT
https://shop.pimoroni.com/products/inky-what

A sárga színű kb 25 másodpercig frissít, de ha csak fekete-fehéret vennék, az pár másodperc, és I2C-n is megy! :)

Vagy a másik ötlet, hogy valami motor átteker vagy átkapcsol valamit, mint ahogy a Technics vagy Pioneer Hifi erősítőjén is ahogy tekerem távirányítóval infrán le vagy fel a hangerőt, úgy a fizikai hangerő gomb is mozog magától. Na, én olyan kijelzőt szeretnék, ami a fizikai kapcsolóval átkapcsolható az automata / kézi üzemmód, és azt ki is jelzi valahogy, csak a kijelzés állapota ne világítson és ne fogyasszon áramot. (Szegény kisbetu, nem akarlak idegesíteni ezekkel, nem ellened megy. Locsemege: tessék itt egy kihívás... ja ez nekem kihívás és nekem hasznos, nem neked.)

Az EINK végülis megfelel a célnak, mert nem világít, mint első megoldás. A sárga tetszik, de az lassan frissül/reagál. Lehet gyorsan kiderítem a lassú frissítés okát, megoldom a problémát és felhúzok Kínában egy gyárat és kiadom az 0,3 másodperc alatt frissülő Y/B/W színű EINK terméket... :-)

Sakk-matt,
KaTT :)

Az épület automatizálási dolgok véleményem szerint ott állnak be, hogy nem integrált a készülő "rendszer", csak összetákolt.

Például valaki vesz valami lámpamegoldást, amit a telefonjáról tud kapcsolni, örül, de aztán rájön, hogy baromi macerás mindig a telefont nyomogatni. Van, aki már vásárlás előtt is rájön, hogy kézzel is akarja kapcsolni, és akkor jön a fejvakarás.

A helyzet az, hogy ezen a téren nem kellene már feltalálni a spanyol viaszt, mert kész rendszerek vannak, csak használni kell őket. A gond velük annyi, hogy nincs mögöttük annyi pénz, mit az Apple/Google és hasonlók mögött, amik a saját böszmeségeiket nyomatják. (a világ mintha afelé tartana, hogy a fűtés szelepet is a felhőből kellene kapcsolni akár a világ másik végéről, ami szerintem nonszensz)
Vannak vezetékes rendszerek, de vannak rádiós rendszerek is (nem Wifi...). A rádiós rendszert jó eséllyel meglévő rendszerbe is be lehet vezetni

Egy lámpa úgy működik, hogy van egy aktor (reléhez hasonló), ami kapcsolja a lámpát, és a telefon, kapcsoló vagy bármi más az aktornak "üzen", hogy fel vagy le kell kapcsolni.
Lehet kapni aktorokat, amikkel kvázi bármit tudsz kapcsolni (nem bármit, mielőtt valaki belekötne, mert egy szivattyút nem tud minden aktor kapcsolni), lehet kapni bináris bemeneteket, amik például kapcsolót érzékelnek és tudnak aktort kapcsolni, de vannak eleve buszra illesztett kapcsolók is, amiket viszonylag gazdagon lehet "programozni". "locsemege" kollégának most lehet, hogy forog a szeme, hogy minek egy kapcsolót ennyire túlvariálni, de egy ilyen rendszernek hatalmas előnye, hogy nem kell már a ház tervezésénél tudni, hogy honnan ki mit akar kapcsolni (másik opció: rengeteg "tartalék kábel"). Például hálószobából kerti lámpa, vagy akár egy több kapcsolós váltókapcsolós felállás. Tervezéskor elég azt kitalálni, hogy hova kell fogyasztó, hova kell kapcsoló.
Ha a fejlődést nézzük, akkor ez viszonylag kézenfekvő: régen volt a barlangban rakott tűz, aztán az épített lakótérben rakott tűz/fáklya, ... aztán megjelent az elektromosság, a lámpákat eleinte ott kellett kapcsolni, ahol voltak, most már a kapcsolók máshol is lehetnek.

Rendszer esetén a redőny is így működik: van egy redőny aktor (ez lehet a redőnynél is vagy egy központi helyiségben is), ami vezérli a redőnyt, és várja a "parancsokat". A parancsok buszon jönnek (a busz fogalma jelen kontextusban viszonylag tág határok között mozoghat, lehet akár ethernet is rendszertől függően), a parancsokat bármi kiadhatja: kapcsoló (kézi, mozgásérzékelő, ...), telefonos alkalmazás, weboldal, ...

Nem tudom, mennyi a kereted, de a helyedben körbenéznék ezen rendszerek között, mert sok mindent nem kell már kitalálnod, illetve esztétikusabb megoldás lehet (kész kapcsolók vannak, amiken akár LED is tud állapotot jelezni stb., szerintem az nem baj, ha egy ház nem elektro-műszerész műhelyként néz ki). Pénzben nem olcsók ezek, de van igény, amit másként nem tudsz normálisan megcsinálni egyetlen projekt keretében. Az is egy lehetőség, hogy bizonyos kapcsolókat/lámpákat automatizálsz, másokat nem. A lényeg, hogy sok mindenre van már kész megoldás, amik nem is feltétlenül veszik el a bütykölés örömét.

"Az épület automatizálási dolgok véleményem szerint ott állnak be, hogy nem integrált a készülő "rendszer", csak összetákolt."

Hát, én ezt tudva próbálok valamit rendszerben megvalósítani. Lásd ha lehet egységes (hő)szenzorok, egységes működés a helyiségekben, hogy könnyen üzemeltethető, karbantartható, bővíthető legyen. Ethernet alapú kapcsolat, és egységesen RPI platform, egységes OS, Network boot, központi backup, offsite backup, stb.
A szenzor kereteket is keresem most, fürdőszobába egyedi lesz, a többi helyen azonos. Olyat néztem volna, ahol a fény érzékelő szenzor és a hőmérő / páratartalom is együtt van, de nem találtam még jót. A fényszenzort légmentesen le lehet zárni, plexi / üveg kell neki, nem fog porosodni, kívülről törölhető. A páratartalomhoz meg kb lyukacsos, csíkokban lyukas tokok vannak. Most nézegetem luxus otthonvezérlő rendszereknek a szenzorjainak a külső megoldását. Sok esetben egyszerűen el van rejtve a páratartalom szenzor egy ventilátorban vagy valahol, valami más egységben.

"a világ mintha afelé tartana, hogy a fűtés szelepet is a felhőből kellene kapcsolni akár a világ másik végéről, ami szerintem nonszensz"

Én is ezt látom és egyezik a véleményünk.
Nálam csak helyi hálózatról lehet majd vezérelni később, mint sokadik kör, és a lesz nyilván kézi megoldás, ami az alap.
Első pár kör kizárólag a statisztikai adatok. A relék és egyéb egy későbbi kör, mert minden, ami vezérelhetőnek gondoltam az úgy van kitalálva, hogy manuálisan és relével is kapcsolható.

"Nem tudom, mennyi a kereted, de a helyedben körbenéznék ezen rendszerek között, mert sok mindent nem kell már kitalálnod, illetve esztétikusabb megoldás lehet (kész kapcsolók vannak, amiken akár LED is tud állapotot jelezni stb., szerintem az nem baj, ha egy ház nem elektro-műszerész műhelyként néz ki)."

Körbe néztem, és próbálok kész elemeket kapni. Fentebb írtam, hogy például nem akarom, hogy világítson egyetlen állapot jelző sem. Talán egyetlen kitétel a fürdőszoba lámpa, ahol egyértelműnek kell lenni, hogy van bent valaki, a rozetta jelzése nélkül.

Sakk-matt,
KaTT :)

http://www.nonan.net/nkruse/electromagnetic_7-segment_display

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Köszi, de ez világít. Nekem olyan kijelző kell, ami sötétben láthatatlan. Nem akarom fényérzékelővel megoldani, hogy ha sötét van, lekapcsolja a LED kijelzőt, újabb overkill lenne, amit el akarok már kerülni :)

Eddig az EINK a nyerő, mint az Amazon e-könyv olvasója: sötétben nem látszik, fényben olvasható.
Az a koncepció, ha sötét van, ne legyen semmilyen nem oda való zavaró fény / kijelző látható. Legyen sötét, klasszikusan.
A szobák nem repülőgép pilótafülkék, ahol éjjel-nappal látni kell a különböző eszközök és szenzorok állapotait. Nem akarom látni sötétben, hogy a redőny vezérlés automata vagy kézi üzemmódban van. Sem a hőfokot, stb. Elég, ha már működik az automatikus klíma vezérlés, akkor 28 foknál bekapcsol a klíma, akkor ebből tudom, hogy 28 fok lett. Ha meg kikapcsol, tudom, hogy 23. Nem kell látnom, hogy már 24 fok van, és már csak 1 fok és kikapcsol. Ha érdekel, megnézem a pontos számot valamilyen módon a központi RPI-ről kiolvasva. (Példák.)

Én ezt a "kevesebb kijelzés több" nézőpontnak hívom. Mert nem látom feleslegesen, amit nem kell, hogy lássak sötétben.

Sakk-matt,
KaTT :)

Nem világít az. Elektromágnes beforgatja a fényvisszaverő fehér szegmenst, a remanens indukció pedig pozícióban tartja, így csak az átváltáshoz kell áram, a pozícióban tartáshoz nem. Ha jól sejtem, nagy hiszterézisű ferromágneses anyagot használnak.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Köszönöm, akkor ez is megoldásként a listára került! :)

Sakk-matt,
KaTT :)

olyan is lehet, hogy elso gombnyomasra bekapcsol egy led hogy kezi vagy autoomata uzemmod es csak a kovetkezo gombnyomasra csinal valamit.

A kezi /automata ledsor meg 20sec utan elalszik.
Lehet uveglap es kapacitiv.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

A Bosch CAN busz - IP modul leírása:

http://www.bosch-semiconductors.com/ip-modules/can-ip-modules/

Találtam egy eszközt, ami CAN-Bus - LAN adapter, 50 ezer Ft:

http://www.visionsystems.de/produkte/netcan-plus-110-netcan-plus-120-wlan.html
https://shop-visionsystems.de/en/ethernet-to-can-bus/424-netcan-plus-110.html

Ez talán arra lehetne jó, ha több telephely lenne, és mondjuk VPN-en elérném a többi telephely szenzorjait így. Ezt csak mint elméleti lehetőség említem meg, az én céljaim szempontjából keresek olyan megoldást, ami még egyszerűbb.

CAN busz - Ethernet átalakítók: Látszólag az összes gyártó hasonló megoldást csinál, mert nagyon hasonló a funkciójuk:

https://www.alibaba.com/product-detail/Ethernet-CAN-interface-130mA-CAN-Bus_60742457326.html
External voltage (DC+9~30V), current (DC+24V 50mA)

Ennek van a legjobb leírása.

Tudja, ahogy a lenti további 2 eszköz is:

TCP Server mode
TCP Client mode
UDP mode

Ez:

https://www.aliexpress.com/item/1-Channel-CAN-Bus-to-Ethernet-TCP-IP-Serial-Device-Server-DC8-38V-Free-Expedited-shipping/1582407229.html

Vagy ez:

https://www.aliexpress.com/item/Ethernet-to-CAN-CAN-Ethernet-2-channels-CANbus-to-TCP-IP-isolated-Adam-module-Din-Rail/1871003760.html

Azért itt a fenti terméknél komoly, hogy van rajta RS232, majd oda van írva: "(Please note, RS232 interface is unusable yet.)"

Ez is:
https://www.aliexpress.com/item/CANET-2-Ethernet-to-CAN-Interface-Converter-2-Way-CAN-Bus-to-LAN-TCP-IP-Data/33020300707.html

Van 4 utas CAN busz, a fentiek 2 utasak:

https://www.aliexpress.com/item/2pcs-lot-Free-shipping-NE5532-subwoofer-tone-board-low-pass-circuit-board-PCB-bare-board/32607272268.html

Külön jó az URL-je, mert a termék neve: CAN to Ethernet 4 way CAN bus industrial grade stable CNET400

https://www.aliexpress.com/item/CAN-bus-to-Ethernet-Modbus-TCP-module-gateway-GCAN-205/32998965689.html?

Ennyi első körben a CAN busz - Ethernet gyűjtésem.
Más irányt keresek, mint pont ez, sima CAN busz - SPI jellegűt.

Sakk-matt,
KaTT :)

Eléggé jó bírod a kritikát és szurkálódást is. Le a kalappal, nagyon azt látom hogy olyan helyen tapogatózol amiről kb. 0 fogalmad van.
Így könnyen beleeshetsz abba a hibába hogy nagyon nem az lesz a vége amit megálmodtál.
Másfelé írtad, hogy sw-ben otthon vagy nagyon de hw-ben nem. Ez látszik is.

Javíts ki ha tévedek de te ilyesmiben gondolkozol:


                                   +~~~~~~~[CAN-spi-MCPxxx]
[RPI-spi-CAN]~~~~~~[CAN HUB (WTF???)]~~~~~~[CAN-spi-hőfok érz.]
                                   +~~~~~~~[CAN-spi-I/O bővítő]

Ahogy én tudom ez így nem fog menni.

Ez már lehet egy használható megoldás lehet:


                                         +~~~~~[CAN-spi-uC-spi-MCPxxx]
[RPI-ETH]~~~~~~[ETH SW/HUB]~~~~~[ETH-CAN]~~~~~~[CAN-spi-uC-I2C-hőfok érz.]
                                         +~~~~~[CAN-spi-uC-GPIO-I/O bővítő]

Az I2C, SPI, vagy legyen az akármi akár csak CAN is csak az 1-2 réteg ha OSI rétegként nézzük. Az hogy belül mi közlekedik nem azonos minden esetben.
Tehát az a CAN-SPI panel nem konverter, hanem illesztő. Ha RPI-re rászereled, akkor van lehetőséged egy hálózati interfészként kezelni a továbbiakban.
Az SPI-buszt ilyen esetben talán a PCI-hoz hasonlítanám neked.
Ha összedrótozol két PCI-os hangkártyát az egyik analóg a másik Optikai ki és bemenetekkel van, akkor nem lesz belőle átalakítód a két hangot hordozó közeg között. Kell közzé processzor és program. Talán így érthető a dolog.
Másik oldalról közelítve, az az SPI-CAN illesztő parancsokat is vár, pl. mekkora sebességgel menjenek a bitek, legyen-e benne szűrő, és egyéb ilyen dolgok.

Amennyi időd elmenne a saját CAN hálózattal stb... inkább javaslom hogy RPI mindehová, ott rá amit akarsz, van SPI-ra is lehetőség és I2C-re is, sőt akár GPIO-ra is. Ezt pedig etherneten húzd össze, az hogy wireless (WiFi), vagy kábele, optikás, ilyen olyan tunnel, VLAN, az már más tészta.
Vagy MODBUS-RS485 irányában nézelődj kicsit. Ott is lehet egy darabon ethernet a közeged.

"Eléggé jó bírod a kritikát és szurkálódást is. Le a kalappal."

Senki nem kényszerített, hogy befeküdjek a pofozógépbe. Jogosak a kritikák, a szurkálódás pedig stílus és habitus kérdése. Ez az ára, hogy magamhoz képest a leggyorsabban akarok fejlődni. Nekem ez így járható út, és haladok a cél felé. Szebb lenne, ha hetekig csak specifikációkat olvasnék, sokkal relevánsabb kérdéseket tennék fel, vagy nem is kérdeznék. Így viszont a válaszokból azokra a témákra fókuszálok elsőnek, amik a cél felé visznek, és a többi elmélet pedig párhuzamosan a helyére kerül.

"nagyon azt látom hogy olyan helyen tapogatózol amiről kb. 0 fogalmad van"

Jól látod. Eldöntöttem, hogy úszni fogok, úgy, hogy nem tudok úszni, de nagyon akarok. Kitűztem célnak, hogy 1 perc alatt leúszom mellben a 100 métert. Beugrottam a vízbe, és majdnem megfulladtam, de már láttam a hiányosságaimat. Most úszó edzésre járok, edzem az úszáshoz szükséges izmaimat, olvasok erről. Lehet, nem érem el hónapokon belül az 1 perces olimpiai szintidőt, de már a 2-3 perc is elég lehet ennyi idő alatt, és ha fontos, akkor még fókuszálok rá.

"Így könnyen beleeshetsz abba a hibába hogy nagyon nem az lesz a vége amit megálmodtál."

Így van, minden tervnek meg van az a kockázata, hogy nem valósul meg. Azonban én mint legrosszabb lehetőség én azt látom, hogy én nem tudom megépíteni ezt a szükséges kábelezéssel, és valaki ezzel foglalkozót fogok kifizetni a megvalósításra. Esetleg csak bizonyos részfeladatára.
Mivel a helyiségekbe oda van húzva a célnak megfelelő, sőt, talán az indokoltnál jobb kábel is, több is, így nem tűnik reálisnak, hogy ne legyen VALAMI megoldás. Lennie kell. Van. Az is lehet, hogy ha elkészül, majd évek múlva látni fogom, hogy mennyivel jobban, észszerűbben is lehetett volna, más hardverekből. Akkor vagy javítom, vagy elfogadom, hogy akkor, én ezt így tudtam maximum és ha működik, akkor működik. Mivel ez nekem hobbi, egy újabb megvalósítandó cél, továbbá szórakozás, kihívás, így ha elkészül, onnantól várhatóan kis prioritással fogok tovább ezzel foglalkozni és lehet, hogy újabb kihívást keresek. (Ez a komment megírása után percekkel a www.nasa.gov -tól írtak angolul, hogy kifejezetten kérik, hogy NE kérdezzek a szakmai fórumokon, küldik a szenzoros műholdat és egy NASA-s pólót, csak kerüljem el őket a kérdésimmel! :)

"Másfelé írtad, hogy sw-ben otthon vagy nagyon de hw-ben nem. Ez látszik is."
Ha hardverben képben lennék, nagyon nagy erőfeszítés lenne ilyen triviális és alapismeretek hiányára utaló kérdéseket feltenni! :)


Állatkertben:
- Apu ez milyen állat?
- Nem tudom.
- És ez, milyen állat?
- Nem tudom.
- Hát ez, milyen állat?
- Nem tudom.
Az anya közbeszól:
- Móricka hagyd már békén apádat!
Mire az apa:
- Hagyd csak szívem, úgy tanul a gyerek, ha kérdez!

"Javíts ki ha tévedek de te ilyesmiben gondolkozol:
[RPI-spi-CAN]~~~~~~[CAN HUB (WTF???)
Ahogy én tudom ez így nem fog menni."

Hát, én a megoldást keresem, legyen az bármi, ami kábelen átküldi a szenzor adatokat RPI-nek.
Amit írtál, az is felmerült, mint lehetőség, mert nem találtam MÉG jobbat. Viszont úgy néz ki, írtál egy jobb utat:

"RPI-ETH]~~~~~~[ETH SW/HUB]~~~~~[ETH-CAN]"

Tehát Ethernet-en az RPI eléri az Ethernet-CAN busz adaptert (pont a post-od írása előtt, azaz már tegnap kezdtem gyűjteni az infókat a CAN-Ethernetről, mert ez is egy út, amit találtam), majd a CAN buszon (ahova Etherneten jutottam el) SPI illesztővel a szenzorokat, jól értem?
Ez a megoldás tetszik, csak az nem, hogy 50 ezer Ft-ért találtam egy CAN-Ethernet átalakítót erre. Te tudsz esetleg ennél jobb áron?
Továbbá én azt gondoltam, hogy kihagyhatom az Ethernet-et, mint továbbító layer, és máshogyan fog menni a szenzor adat.
Én ezt mint a másik hozzászólásban írtam, 100+ méter vagy más telephelyes távolságoknál használnám. Lennie kell a 20-30 méterre is valami más megoldásnak, azt tippelem.
Továbbá akkor úgy lenne szép, hogy a CAN + Etherneten lekérdezett szenzorok egy (fizikailag is) külön hálózaton kommunikálnak, akkor VLAN vagy külön switch, ami megint egy komplexitást ad a megvalósításhoz.

Igen, köszönöm, érthető volt, hogy miért kell illesztő / átalakító az SPI és CAN közé, és hogy mit csinál.

"Vagy MODBUS-RS485 irányában nézelődj kicsit. Ott is lehet egy darabon Ethernet a közeged."
Gondolatolvasó vagy, ez a következő, amilyen irányban még nézelődni fogok. (Kisbetu már (ki)készülhet! :)

Végignézem az elvi lehetőségeket, és ha nincs megfelelő megoldás, még tovább keresek. Mert az a megérzésem, hogy több úton (különböző átviteli protokoll / megoldás / interfész / illesztő) használattal is meg lehet oldani ezt. Szempont az ár/érték arány és a bővíthetőség és könnyű megvalósíthatóság, valamint a minél üzembiztosabb működés.

Az a lista végére került, mint megoldás, hogy mindenhova rakjak RPI-t és szenzorokat, mert 1-1 SBC üzemeltetése helyiségenként túl sok üzemeltetési feladat, nagyobb elromlási lehetőség és felesleges áramfogyasztás.

Köszönöm a segítséged.

Sakk-matt,
KaTT :)

Szempont az ár/érték arány és a bővíthetőség és könnyű megvalósíthatóság, valamint a minél üzembiztosabb működés.

A néhány uA fogyasztású, néhány percenként lekérdezett szenzorokhoz az Ethernet felejtős a végpontonkénti 1W fogyasztás miatt.

Ha szeretnél >20m kábelhosszon is dolgozni, akkor nem érdemes két különböző megoldást használni.

Az ipari kábeleket is el lehet felejteni, mert az áruk legalább 2 nagyságrenddel haladja meg az egyszerűbbekét. A hozzávaló csatlakozó is jóáras. Igaz, ha egy teherautó rááll, akkor sem változnak az elektromos paraméterei. Van olcsó, 5m di2c kábelem 70eFt-ért. ;)

A fentiekre a legegyszerűbb a CAT# kábelhez:
SDA = MAX485 - - PCA9600 - I2C - (MCU) - I2C (RS232)- [HUB] - rPi
SCL = MAX485 - /
GND =
VDD =
A = jel egy érpárat jelent.
Az MCU akkor szükséges, ha cím azonos címek is vannak vagy protokoll konverzió szükséges. A plusz költség csak 300Ft.
Szóval ilyen modul kell minden szenzorhoz.
Ha minden szenzorhoz kerül MCU, akkor elég egy MAX485, és tetszőleges lehet az eszközök címzése.
A HUB egy roppant bonyolult szerkezet!!!!
Egyszerűen az aktív vonal meghajtóit engedélyezi, amihez kábelenként egy GPIO elegendő.
A 20m-es hossz alatt a MAX485 elhagyható, bár csak 30Ft darabja.

Vezeték nélkül pedig a sub MHz adóvevőket javaslom, ami szintén alacsony fogyasztású.

Rakom össze ez alapján az egyik lehetséges megvalósítási tervet, addig képek az RS-485 BUS-hoz:

https://i.imgur.com/8l9GMTn.jpg

Kábel bekötése az ES-485-nek:

https://i.imgur.com/ilJI6JG.gif

Tehát 3 ér kell neki:
DATA (B)+
DATA (A)-
GND

és ezeket sorban, láncszerűen (daisy chain) összekötöm?
Tehát oda megy a központi helyiségből (ahol az RPI van), az RPI interfészéből indulva 3 ér az első helyiségbe, ott bele az ottani helyiség interfész eszközbe (I2C / SPI?), majd onnan visszajön másik 3 éren a központi helyiségbe és ott a második helyiség 3 kábelén odamegy a második helyiségbe, ahol belemegy az ottani második helyiség interfészbe (I2C / SPI?), és onnan visszajön a központi helyiségbe, ahol megy a harmadik helyiségbe... és a végén lesz egy 120 Ohmos ellenállás, ha nincs több szoba, és ez 1200 méter lehet maximum, ami itt jóval kevesebb lesz.

a helyiség interfészeken meg lesz az 1-3 szenzor helyiségenként.

Ha jól értem, akkor ezt ábrán is lerajzolom és felrakom ide.

Sakk-matt,
KaTT :)

Szia!
Én ilyen, hasonló RS485- ös megoldást csináltam otthon 15 évvel ezelőtt. Több átalakítást is gond nélkül elviselt. A master egy PC volt, most laptop, de ez most mindegy. Amit kérdezni akartam, hogy miért a CAN busz irányában spekulálsz?

"Tehát 3 ér kell neki:
DATA (B)+
DATA (A)-
GND"
Én az eszközeim +24V tápját is a "busz- kábelben" vittem, tehát 4 érrel, illetve csavart érpárokkal dolgoztam.
--
üdv: virtualm

Szia, köszönöm az infód.

Előzőlegesen a hozzászólásod, azaz miután hozzászóltam ez a hozzászólás alatti, 2019. június 18., kedd - 18:59 hozzászólás végén kiemelt rész szerinted megvalósítható azokkal a hardverekkel és úgy, ahogy tanácsolták és próbáltam "visszamondani"?

Nekem Raspberry Pi lenne a master. Milyen módon csatlakoztattad az RS485-öt a PC/notebook-hoz? Az az interfész kártya azóta is megy?

"Amit kérdezni akartam, hogy miért a CAN busz irányában spekulálsz?"

Azért, mert onnan indultam, hogy I2C-s (és SPI-s) szenzorokat szeretnék több helyen, kábelezve, majd kiderült, hogy pár esetben szükséges a 20-30 méteres távolság, és ott az I2C busz önmagában kevés.

Mivel soha nem csináltam ilyen buszos kommunikációt hardveresen, csak különböző szoftvereket és szabványokat használtam interfészként és API-ként, így nincs gyakorlati tapasztalatom eldönteni és megítélni, hogy a céljaimra van-e jobb megoldás, mint a CAN busz, vagy más. Az I2C és az SPI az bizonyos esetben túl rövid hatótávolságú, alapból.

Bemásolom ide is neked, a lényeget:

Cél:
- például 8 helyiségben lévő helyiségenként 1-3 szenzort (hőfok, pára, légnyomás, fény[lux], stb) (ami jelen helyzetben még I2C vagy SPI-s, de lehet bármi más is) rendszeresen lekérdezni (1-x percenként, vagy fél percenként)

Kötöttségek:
- Ki van húzva csillagpontosan több 8 eres, 4 érpáros, árnyékolt / dupla árnyékolt CAT6A és CAT7A S/FTP kábel az akár 30 méterre lévő helyiségekbe, amit tudok erre a célra használni, a csillagpont közepében lesz ami az egészet kezeli, vezérli
- Ha lehet, a kis fogyasztás, olcsó üzemeltetés miatt Raspberry Pi-ben gondolkozom, mint központi szerver (ami PXE boot és NFS-en fut NAS/Shared storage-ről).
- Ha lehet, ezeket a kábeleket akarom használni.

Ahogy lentebb írtam és buckó javasolta, annak milyen előnyét, hátrányát látod erre a célra?

Elmondanád, hogy te hogyan valósítanád ezt meg, a sajátodhoz hasonlóan, vagy jelenleg a rendelkezésre álló eszközökből, amiket most lehet kapni, és most akár a sajátodat is úgy csinálnád? Még jobb lenne, ha a javasolt megoldásod szenzorai könnyen megoldhatóan, megbízhatóan 3,3VDC-vel menne, mert ilyen szenzorokat ismerek leginkább. A BME680 már szépen megy, I2C buszon. Jövő héten a fény szenzort fogom bekötni, lehet próbából SPI-n, vagy I2C-n.
Nagy segítség lenne, ha az elemek, a kábelen kívüli adapter, interfész, illesztő kész, megvehető termék lenne, amit én is könnyen tudnék összerakni és kiépíteni, persze a DIY vonalon belül, de minél kevesebb forrasztással, a kábelezésen kívül.

Milyen eszközeid vannak, hogy +24V-ot kapnak, hány darab, milyen minimum-maximum távolságra? Meghibásodás? Árnyékolt vagy árnyékolatlan kábelen vitted a 4 eret?

Köszönöm a segítséged.

Sakk-matt,
KaTT :)

Akkoriban delphi(7) fejlesztés volt napirenden és e miatt onnan indultam ki, hogy mit tudok azzal megcsinálni, mihez, hogyan tudok drivert és hardvert illeszteni. A cél az volt, hogy a (180m2, 3 szint) házam központi fűtését optimalizáljam és ne a feleségem kedve szerint legyen a termosztát tekergetve, majd a gáz számla fizetgetve. 10 kulcsfontosságú helyen hőmérséklet és pára tartalom mérése, adatbázisba töltése és grafikus megjelenítése, távoli elérés miatt szolid weblapon publikálva. Ezek alapján a radiátor szelepeket beállítva és a mindenkori hőfok igényt az élethelyzethez igazítva, jelentős megtakarítást értem el. Az évek során a szobák funkciója változott ezért a szoftver folyamatosan módosult, vezér helyiségek és értékek változása miatt. A CAT5- ös kábelezés struktúrája módosult, de jelentős zavar nem keletkezett. A saját készítésű eszközöket percenként lekérdezve, mentve, kiértékelve, beavatkozva, még bőven maradt ideje a PC- nek bármire is. A COM-RS485 átalakítón, CAT5 kábelen keresztül, minden eszköz saját címen lekérdezhető, ( master- slave ), illetve a relés modullal vezérlem a cirkót, a hagyományos szoba termosztát helyett. A kutyaház fűtés is erre az RS485 vonalra lett rákötve. A több darab utólagos kábelezés, leágazás ugyan elrontotta a szép busz topológiát, de a zavarok kezelhetőek maradtak. Az évek folyamán a PC- COM- RS485, helyett laptop és USB_COM- RS485 lett, a kiépítések adottságai miatt.

Ma már nem saját tervezésű és építésű eszközökkel csinálnám, de annó ( nem is 15 hanem 20 éve ) az egy jó, tanulságos, de drága móka volt. Úgy látom, hogy túl is lett variálva a dolog, külső hőmérőkkel ( észak- dél) szélmérővel, eső szenzorral, de hát a "fiatalság bolondság". Voltak hasznos kiegészítések is, ajtónyitás érzékelése, klíma ki- be kapcsolása, állítása a buszon lógó infrán keresztül, de ezek a jópofa dolgok is inkább mint szakmai kihívások voltak jelen. Ma már az eszköz készlet lehetősége, a szoftveres ellátottság és tudás nyilván más irányba terelne. Maga a tervezés, a megcsinálás, a módosítgatás jó szórakozás volt. Ránézve a 20 évvel ezelőtti programra, nem repesek az örömtől, mert sok felesleges dolog van benne, de nem érek rák kijavítani, mert működik és lusta vagyok.

Hú, ez akkor igen komoly rendszer, főleg megépítve. Gratulálok hozzá és külön tisztelet a kitartásodhoz, hogy akkor ezt megépítetted valahogy és lekódoltad hozzá a szoftvereket, tehát komplett rendszert hoztál létre. Most jóval könnyebb dolgod lenne.

Ha nem lennének kész hardver modulok, lásd I2C/SPI-s szenzorokból nagyon sok típus és fajta, hozzá kész Linux támogatás, hogy egyből leolvasható a szenzor, és tesztnek több alkalmazás, ami egyből grafikont rajzol, akkor most nem fogtam volna hozzá. De így hogy adottak a hardver elemek és a szoftver támogatás, gyorsan lehet eredményeket elérni... Még ha el is veszik annak az öröme, hogy veszek egy hőfok szenzort, tervezés, dokumentáció és szabvány bújás, megforrasztom a nyákot hozzá, bekalibrálom, és a saját fejlesztésű driveremmel kiolvasom az értékét valahogy, mindezt hetek és hónapok alatt. Tudom, így lenne az igazi kihívás.

"Úgy látom, hogy túl is lett variálva a dolog, külső hőmérőkkel ( észak- dél) szélmérővel, eső szenzorral, de hát a "fiatalság bolondság"."
Én is most ezen a szinten vagyok... még :)

"Maga a tervezés, a megcsinálás, a módosítgatás jó szórakozás volt."
Nekem is az, csak még kevés a sikerélményem, de már van valami. Már látom a potenciált, hogy mennyi mindent ki lehet ebből hozni. Tudom, hogy van ami túlzás, de attól még kíváncsi vagyok, hogy fog működni.

Sakk-matt,
KaTT :)

Köszönöm a konkrét tervet.

Tehát próbálom összerakni a megoldást lépésenként, hogy jól értem-e.

Akkor ez csillagpontos lesz, tehát a központi helyiségből, ahol az RPI és az összes kábel befut, onnan elég 1 darab 8 eres CAT6A vagy CAT7A kábel, amiből érpáronként 1-1-1-1 eret fogok használni:
SDA
SCL
GND - föld, az RPI GPIO lábáról?
VDD - 3,3VDC az RPI GPIO lábáról? (vagy 5VDC?)

Vagy 2 kábel kell 1 helyiségbe, hogy 1 kábel oda, és 1 vissza, mert nem lehet csillagpontos?

Veszek ilyet:

MAX485 Module RS485 Module TTL to RS-485 Module (0,1 - 0,3 USD / darab)
https://www.alibaba.com/product-detail/MAX485-Module-RS485-Module-TTL-to_60118200786.html
vagy
https://www.alibaba.com/product-detail/2017-Factory-Outlet-MAX485-TTL-to_60701983879.html

és így kötöm be:

https://i.imgur.com/WFeK4WB.png

Majd az A és B-t viszem, mint busz, továbbá a VDD+GND-t, azaz 4 éret? (a lenti részen máshogyan leírom ugyanezt)

MCU, 1,6 USD:
MCU-219 INA219 I2C Bi-directional DC Current Power Supply Sensor Breakout Module
https://www.alibaba.com/product-detail/MCU-219-INA219-I2C-Bi-directional_60776781931.html

I2C HUB:
https://www.alibaba.com/product-detail/103020006-GROVE-I2C-HUB_60860001620.html
vagy akív I2C hub:
https://store.mrobotics.io/product-p/auav-i2c-hub-mr.htm
vagy:
https://store.mrobotics.io/mRo-JST-GH-GPS-Port-to-I-C-Bus-Splitter-p/mro-jstgh-gps-i2c-split-mr.htm
vagy:
https://www.amazon.com/Headers-Channel-Extender-Expander-Raspberry/dp/B01B3BF4C8

PCA9600 - I2C: (szerintem nem erre gondoltál)
https://www.alibaba.com/product-detail/PCA9600DP-118-IC-REDRIVER-I2C-1CH_60836020800.html
vagy
https://www.alibaba.com/product-detail/PCA9600D-118-IC-REDRIVER-I2C-1CH_60835264568.html

Hanem inkább erre:

PCA9600 - I2C:
https://sandboxelectronics.com/?product=pca9600-differential-i2c-long-cable-extender-with-buck-convertor-2
vagy
https://sandboxelectronics.com/?product=pca9600-differential-i2c-long-cable-extender-with-buck-convertor

Vagy:
https://www.amazon.com/RS485-CAN-HAT-Long-distance-Communication/dp/B07DNPFMRW

Tehát ezekből fogok építkezni, ezek megfelelőek? =============================

Összerakás: =============================

1. RPI - I2C HUB --------------------------------------------------

Az RPI I2C buszára bekötöm az I2C-t, mintha egy szenzort raknék rá:

https://i.imgur.com/vl5OVyL.png

Ezt kötöm rá, tehát kell egy csatlakozó, amibe a 4 eres kábelt kötöm:

I2C HUB:
https://www.alibaba.com/product-detail/103020006-GROVE-I2C-HUB_60860001620.html
vagy:
https://store.mrobotics.io/product-p/auav-i2c-hub-mr.htm
vagy:
https://store.mrobotics.io/mRo-JST-GH-GPS-Port-to-I-C-Bus-Splitter-p/mro-jstgh-gps-i2c-split-mr.htm
vagy:
https://www.amazon.com/Headers-Channel-Extender-Expander-Raspberry/dp/B01B3BF4C8

Mivel több, mint 4 HUB kell, így veszek N darabot, hogy az összes helyiséget rá tudjam kötni a HUB-ra,ez is így oké?

2. MCU --------------------------------------------------

Aztán a HUB I2C csatlakozóira MCU:

MCU-219 INA219 I2C Bi-directional DC Current Power Supply Sensor Breakout Module
https://www.alibaba.com/product-detail/MCU-219-INA219-I2C-Bi-directional_60776781931.html

Itt a 4 eres kábelt bekötöm ahogy kell:

Az egyik oldal 6 ér jöhet be:

VCC: 3,3VDC
GND: föld
SCL: SCL
SDA: SDA
Vin+: ide mit? semmit?
Vin-: ide mit? semmit?

Majd az MCU kimeneténél:
Vin-: DATA (B)+ ? vagy más?
Vin+: DATA (A)- ? vagy más?

Tehát az MCU 2 eres kimenete lesz az adatbusz indulása, és mellé kerül a
VCC: 3,3VDC
GND: föld
, így lesz meg a 4 ér, de ezt az utóbbi kettőt direktben kötöm be az I2C HUB kimenetéről

Tehát most ott tartunk, hogy van buszra átalakított A+B, és VDD és GND, 4 ér, ezt kötöm be így a 8 eres CAT# kábelhez, érpáronként 1-1-1-1 kábelt.

A CAT# kábel a központi helyiségből, ahol mindez volt, át van kötve a helyiség 1-be. Ott lesz már bekötve a 4 érből:

3. MAX485: --------------------------------------------------

MAX485 Module RS485 Module TTL to RS-485 Module (0,1 - 0,3 USD / darab)
https://www.alibaba.com/product-detail/MAX485-Module-RS485-Module-TTL-to_60118200786.html
vagy
https://www.alibaba.com/product-detail/2017-Factory-Outlet-MAX485-TTL-to_60701983879.html

Bekötöm a fenti módon, hogy az A és B + GND + VDD a CAT# kábelből jön, és visszakapom az I2C buszhoz szükséges 4 eres kábelt

Így most van egy I2C buszom, ami olcsó, ám igazán mozgalmas és érdekes úton kap elektromosságot.

4. szenzor 1: --------------------------------------------------

Ezt az I2C busz 4 kábelt, ha optimista vagyok, úgy kötöm be, mintha simán az RPI-re kötném rá, tehát bekötöm az I2C-nek megfelelően a szenzort. Ha kell akkor lekötöm a lábát, ha kell, akkor fel.

Kész, így működni fog?

Tehát visszafelé nézve a szenzortól:

4. Szenzor 1 4 éren (SDA+SCL+VDD+GND, I2C-nek megfelelően küldi az adatot (kérésre, de most visszafelé megyünk)
kábel: (sima, rövid 4 eres kábelen összekötöm)
3. A MAX485 kap 4 eret I2C-ként, és csinál belőle A+B+VCC+GND-t
kábel: (itt a CAT6A vagy CAT7A kábelen, 8 éren, 4érpáron, érpáronént 1 ér adatot kötök be: A+B+VDD+GND )
2. Az MCU kapja CAT#-ból a 4 eret (A+B+VDD+GND) és csinál belőle újra I2C-t (SDA+SCL+VDD+GND)
kábel: (sima, rövid 4 eres kábelen összekötöm, 4 eres csatlakozó lesz az I2C HUB-ba kötve)
1. I2C HUB-hoz ért a 4 ér, csatlakozón keresztül
kábel: (A HUB-ból kijövő 4 eres csatlakozót szépen az RPI-be kötöm, a megfelelő helyre)
0. RPI-ben az I2C-hez szükséges PIN-ekre bekötöm a HUB-ból jövő 4 eres kábelt.

K1: Jó így, ahogy fentebb 4-0 között leírtam?

K2: A többi szenzort ugyanígy, csillagpontosan kell bekötni az I2C HUB-ba és kész?

K3: Ha van MCU, akkor hogy oldódik meg a szenzorok I2C ID ütközése? Hogy fog látszódni, ha van 6 darab 77-es ID-jű I2C hőmérséklet szenzor az I2C HUB-ra kötve, a fenti módon bekötve?

K4: Hogy látom majd a szenzorokat, I2C buszon? Milyen ID-vel? Hogy állítok ID-t, ha kell?

K5: Így kell ide bármilyen ellenállás? Ha igen, akkor hova? Azt tippelem, hogy nem, mert az RPI-ben van.

K6: Így 1 darab I2C buszom lesz összesen, tehát az RPI alap buszára lesz kötve, és ennyi?

K7: Így akkor gyakorlatilag az I2C buszom hossza, az a RPI és I2C HUB, valamint az I2C HUB és MCU távolság, persze annyiszor I2C HUB és MCU, ahány szenzor van?

Még egyszer köszönöm (mindenkinek), hogy időt szánsz arra, hogy össze tudjam ezt rakni.

Sakk-matt,
KaTT :)

Ha egy József Attila verben is vannak hasonló betűk, attól még nem biztos, hogy ide is jó lesz. :-D

Pl.: Waveshare RS485 CAN HAT = SPI meghajtású CAN controller RS485 hardveren keresztül illesztve a kábelhez. De ezt Te is ugyanúgy el tudtad volna olvasni, mint én. Eközben harmadszor írom le, hogy NINCS CAN PROTOKOLL (ebben a szenzoros rendszerben), és az SPI-t sem kellene idekeverni!

Az RS485 (-szerű) vonal lezárása 100 Ohm, mert az UTP és hasonló kábeleknek is annyi az impedanciája. Ha feltétlenül ragaszkodsz a "szintre húzáshoz", akkor az ábrán az alsó tag 600-120-600 Ohm, de elég a 100 Ohm is.

Az RS485 úgy néz ki, hogy van két drót - B és A. (Legyen most csavart érpár!) A két drót mindkét végén össze van kötve 100 Ohmos ellenállással. Ezek után tetszőleges helyre köthetsz eszközöket a következő módon: A-ra A-t és B-re B-t. Persze a drótot két csatlakozóval megszakítva a kapcsolás sorosnak tűnhet, de nem az. ;) Viszont lehet tetszőleges alakú a drót hajtogatása.

A fenti topológia szerint a csillag első és utolsó ágának a végére kell a lezárás. A többi ág mindig az előzőtől kapja a vonalat egy érpáron, majd a kábel végétől visszafordul a másik érpáron. A tápot meg a központtól kapja minden egyes ág.

A MAX485-nek 5V kell! Ennek ellenére a logikai jelek lehetnek 3,3V-osak.

Ebben az esetben minden egyes szenzorhoz vagy szenzor csoporthoz kell egy MCU protokoll koverter. Ez a soros vonalon használt, akár általad kitalált protokollt kezeli. A másik oldalon meg az egyes szenzorok lekérdezését kell megcsinálni.


Az i2c megoldásra idemásolom a múltkorit:

Ami feltétlenül drága, az pl. a "P82B715 Module" az 5000Ft-os árával. Egy ilyet kis sorozatban legyártva, még az európai árakkal sem lesz feleannyi sem!
Pl.: P82B715 100Ft/db.

Sajnos nem vehetsz meg minden modult, mert brutális ára lesz, és ennek ellenére sem tudja a feladatot.

Ebben az esetben csillag a olcsóbb topológia, de az aktív i2c HUB nem meghajtó! (PCA9516A, 5-channel I2C-bus hub - The I2C-bus capacitance limit of 400 pF restricts the number of devices and bus length. Using the PCA9516A enables the system designer to divide the bus into five segments off of a hub where any segment-to-segment transition sees only one repeater delay.)

Az egyik megoldás, ha összekötjük a csillagot, hátha elbírja a meghajtó. (3000pF)

Ha nem, akkor az SCL és SDA jeleket egyszerre csak egy ágról szabad bekötni a központba, míg a többi ágat leválasztani. Erre a címek ütközése miatt is szükség van.


Eddig nyúlott. :)

Többet akkor sem tudok segíteni, ha az egész internetet idelinkeled.

Szerintem döntsd el, hogy az első megoldás legyen! ;)
Ahhoz nem kell egyedi áramkört építeni, csak MCU-t programozni.
Viszont nics cím ütközés és bármilyen szenzort rá tudsz akasztani.

Szerintem József Attilát ne keverjük ide, mert egyrészt nem tudjuk, hogy mielőtt elhunyt, az előtt milyen otthon automatizálási problémával találkozott és mivel nyilvánvalóan nem tudta egy szakmai fórumon megkérdezni, így a következményeket ismerjük. Persze lehet, hogy egy párhuzamos univerzumban történt így, nem itt. (Elnézést a viccelődésért, ha velem fordított esetben viccelődnének így, én nem haragudnék és nekem nem lenne gond biztosan.)

"Pl.: Waveshare RS485 CAN HAT = SPI meghajtású CAN controller RS485 hardveren keresztül illesztve a kábelhez. De ezt Te is ugyanúgy el tudtad volna olvasni, mint én. Eközben harmadszor írom le, hogy NINCS CAN PROTOKOLL (ebben a szenzoros rendszerben), és az SPI-t sem kellene idekeverni!"

Igen, igazad van, újra és újra. Ha utána olvastam volna és értelmezni próbáltam volna a "via" szót a "CAN function, onboard CAN controller MCP2515 via SPI interface" kifejezésben, az segített volna, hogy legalább ne írjak hülyeséget erről. Erről se.

Rendben, a lezárás 100 Ohm lesz.

Rajz (terv_v02_02), hogy hogy lesz akkor, ha jól értem, 600 Kbyte, PNG:
https://imgur.com/QCmTF9s

"A MAX485-nek 5V kell! Ennek ellenére a logikai jelek lehetnek 3,3V-osak. "

Az 5.0 VDC-t is az RPI-ről adjam neki ugye?

"Ez a soros vonalon használt, akár általad kitalált protokollt kezeli. A másik oldalon meg az egyes szenzorok lekérdezését kell megcsinálni."
Annyi protokoll van, kivételesen ebben az esetben eltekintenék egy új kitalálásától első körben. Később persze, szívesen bonyolítom.

Nincs erre valami kész megoldás?

MCP2515 CAN Bus Module TJA1050 Receiver SPI Module For 51 MCU ARM Controller DC 5V SPI Interface Control Resistors
https://www.alibaba.com/product-detail/MCP2515-CAN-Bus-Module-TJA1050-Receiver_60830070381.html

Ez is 1,3 USD, ez is használható lehet ide?
Ha erre kötném a A+B-t, az nem segítene bármit is?

Összekötés, példa kábelezés:

https://i.imgur.com/ZNmR4G3.jpg

https://www.14core.com/wiring-the-two-mcp2515-stand-alone-can-controller-with-spi/

"Sajnos nem vehetsz meg minden modult, mert brutális ára lesz, és ennek ellenére sem tudja a feladatot."
Pedig én törekszem rá, hogy inkább vennék modulokat, és azt összekötve megoldani ezt.

"Ami feltétlenül drága, az pl. a "P82B715 Module" az 5000Ft-os árával. Egy ilyet kis sorozatban legyártva, még az európai árakkal sem lesz feleannyi sem!
Pl.: P82B715 100Ft/db."

Hát, ha 2 ilyen megoldaná helyiségenként az összes szenzor összeköttetést, akkor elgondolkoznék, hogy keressek-e tovább.

Részemről az első megoldás jó lenne, ha érteném tisztán az összekapcsolását a moduloknak és rálátnék, hogy az MCU programozás mennyi idő, energia.
Ez a rész így helyes?

"Tehát visszafelé nézve a szenzortól:

4. Szenzor 1 4 éren (SDA+SCL+VDD+GND, I2C-nek megfelelően küldi az adatot (kérésre, de most visszafelé megyünk)
kábel: (sima, rövid 4 eres kábelen összekötöm)
3. A MAX485 kap 4 eret I2C-ként, és csinál belőle A+B+VCC+GND-t
kábel: (itt a CAT6A vagy CAT7A kábelen, 8 éren, 4érpáron, érpáronént 1 ér adatot kötök be: A+B+VDD+GND )
2. Az MCU kapja CAT#-ból a 4 eret (A+B+VDD+GND) és csinál belőle újra I2C-t (SDA+SCL+VDD+GND)
kábel: (sima, rövid 4 eres kábelen összekötöm, 4 eres csatlakozó lesz az I2C HUB-ba kötve)
1. I2C HUB-hoz ért a 4 ér, csatlakozón keresztül
kábel: (A HUB-ból kijövő 4 eres csatlakozót szépen az RPI-be kötöm, a megfelelő helyre)
0. RPI-ben az I2C-hez szükséges PIN-ekre bekötöm a HUB-ból jövő 4 eres kábelt."

Ha nem, akkor melyik részeket kell javítani?

Amit linkeltem képet azt szeretném kapcsolás szinten jóra megcsinálni, 1+N modulra megcsinálva. Ha az úgy jó, akkor beszereznék 3 helyiségre való modulokat és szenzorokat, majd megépíteném a következő prototípust. Ha működik, akkor jönne a még több helyiség bekötésének szimulálása. Ha már minden jól működik, hosszú kábelekkel, utána fogom bekötni a végső helyére. Így lesz, kivéve, ha addig ennél is jobb terv alakul ki, vagy teljesen máshogy alakul. :)

Köszönök mindent.

Sakk-matt,
KaTT :)

No, ez a MCP2515 nem más, mint:
Stand-Alone CAN Controller with SPI Interface
Tehát:
rPi (CAN commands) - SPI - CAN controller - kábel - CAN controller - SPI - CAN commands to I2C bus - sensor

Kihagytad a vastagon szedett részt!

Szóval ugorjál vissza néhány bejegyzést és kezdjél el olvasni!

https://harrisonsand.com/can-on-the-raspberry-pi/

Itt azt írják, hogy az MCP2515 az RPI-vel való kapcsolathoz kell, nem pedig a szenzorral való kapcsolathoz.

Ha jól értelmezem amit írtál:

"rPi (CAN commands) - SPI - CAN controller - kábel - CAN controller - SPI - CAN commands to I2C bus - sensor"

részekre bontva:

rPi (CAN commands) - SPI - CAN controller - kábel - CAN controller - SPI - CAN commands to I2C bus - sensor

Tehát akkor:

1. RPI: RPI 3B+

2. (CAN commands) - SPI - CAN controller:

PiCAN2 CAN-Bus Board for Raspberry Pi 2/3 with SMPS
http://skpang.co.uk/catalog/pican2-canbus-board-for-raspberry-pi-23-with-smps-p-1476.html

Vagy erre javasolnád a
Hot Factory Outlet MCP2515 CAN Bus Module TJA1050 Receiver SPI 51 Single Chip Routines for Uno R3
https://www.alibaba.com/product-detail/Hot-Factory-Outlet-MCP2515-CAN-Bus_60695130682.html?spm=a2700.7724838.2017115.59.17711ddetEcSD9
részt?

A PiCAN2 jó erre a célra?
(Adni kell gondolom ennek a hardvernek is függetlenül 5VDC-t és földet. Ezt az RPI-ből adjam vagy máshonnan? RPI 5VDC vagy külön táp? Föld? )

3. Kábel: 2 eres kábelen ahogy szükséges rákötöm a CAN buszra (A, B) a PICAN2-t. Így ezen keresztül fog az RPI és a másik hardver, ami CAN buszra csatlakozva SPI-re alakítja.

4. CAN controller / MCU:

MCU-219 INA219 I2C Bi-directional DC Current Power Supply Sensor Breakout Module
https://www.alibaba.com/product-detail/MCU-219-INA219-I2C-Bi-directional_60776781931.html

5. Szenzor az MCU-219 I2C buszra, például BME680.

Majd több szenzor esetén a 3. 4. 5. pontot ismételve, buszra kötve a CAN A, B-t?

Így jó, vagy valamit még most is kihagytam és nem működőképes?

Így az azonos I2C busz ID-vel mi lesz? A BME680 csak 2 féle I2C ID-t tud felvenni, és több ilyen szenzort szeretnék. Ezt mivel oldjam meg?

Köszönöm.

Sakk-matt,
KaTT :)

Röviden?
NEM MŰKÖDIK!
Kérlek olvasd el amit régebben írtam és próbáld meg értelmezni.
Akkor is azért írtam, mert volt egy olyan érzésem, hogy úgy gondolod, hogy SPI-I2C-RS485 és akármilyen átalakító az majd átalakít és ÁMMMMENNN.
NEM EZ NEM ÍGY VAN!!!!

Kb. olyan mint amikor ... inkább képpel mutatom.
https://www.geek.com/wp-content/uploads/2010/08/500x_chain-usb1-500x352.jpg

Itt sem működik az LPT portra dugott pendrive.

Az adat és az adatátviteli közeg két különböző dolog az adatátvitel során.

Oké, értem, hogy nem működik.

Próbálkozom, keresem a megoldást. Akkor ezt így kizárhatom, talán pár száz, vagy pár ezer elméleti terv után lesz olyan, amire már páran elfogadtok, mint elméleti út.

Aztán beszerzem majd a hardvert, és lehet elsőre... harmadikra, tizedikre jó is lesz. Mert látom az egyenletben a hiányzó részeket és látom a megoldást is. Csak sok az ismeretlen.

Te biztos akkor azt is érted, hogy keresem a MEGOLDÁST, de konkrétan eddig még senki nem tudta leírni, hogy pontosan mit rakjak az RPI-hez, hogy CAN vagy bármilyen más buszon kommunikáljak csillagpontosan, majd konkrétan mivel lesz jó 20-30 méterre, milyen I2C/SPI modul kell, ami CAN busz és a szenzor között megoldja, amit meg kell.

Többen segítetek ebben, lásd lent és fent, és ezt köszönöm, nem győzöm hangsúlyozni.

Ha megkérdeznéd, milyen hálózati megoldás kell 8 FullHD-s IP kamerának, elmondanám, hogy milyen kábel, milyen kábelfejet javasolnék, milyen switch-et és milyen egyéb egységeket, hogy jól menjen. KONKRÉTUMOKAT írnék, termék linkkel.

Kb így várnék egy konkrét javaslatot egy ideális világban... :-)

Hogy működjön a PC, kell alaplap, RAM, CPU (VGA-val integrált, az egyszerűség miatt), billentyűzet, egér, monitor, és minden működik. Olyan RAM kell, amit az alaplap chipset és és a CPU is támogat, olyan külső VGA esetleg, amilyen busz van az alaplapon, olyan monitor kábel és olyan csatlakozó, ami átviszi a 4K felbontást 60 Hz-en RGB-ben, stb, stb. Írnék konkrét termékeket, amelyekről tudom, hogy együtt működnek, esetleg konkrétan építettem is olyat. Sőt, elmondanám, hogy esetleg mit mivel nem javaslok együtt, X és Y ok miatt, ami elsőre nem nyilvánvaló, de én tudom, és elmondom.

Azt egészen sok helyre oda tudnám írni, hogy NEM MŰKÖDIK.

Természetesen az is nagy segítség, hogy ezt megmondod, mert mint látod, nekem ez sem egyértelmű.

Tudom, hogy sok megoldás van, mindenki a maga által ismertet javasolja, ez is oké.

Nekem egy észszerű, működő megoldás elég, amit részben kész elemekből, vagy teljesen kész elemekből meg tudok építeni, forrasztani, kábelezni, kiépíteni, stb.

Ha sikerül megtalálni, meg fogom osztani a megoldást, mert nekem fordított esetben is jól esne, ha konkrétan olvasnék erről, és nem kérdeznék itt annyit.

Sakk-matt,
KaTT :)

Fentebb leírtam hogyan fog működni.
Lényegében minden szenzorra, kimeneti és bemeneti modulra kell legalább egy mikrovezérlőt tenned, vagy akár számítógépet (pl. RPi), ami az adott kommunikációs közegen legyen az pl. CAN, egy adott nyelvezet szerint (protokoll) kommunikál egymással. Ott kérdezik, mondják, egymásnak az adott információkat.
A kép remélem jól szemlélteti miért nem megy csak simán az átalakítás ide-oda.

Vannak már kész protokollok, pl. MODBUS, ami akár RS232-n RS485, RS422, vagy akár Etherneten is könnyen és már szabványosítottan közlekedik.

Azért ezt írom, mert sok esetben ilyen adatcserére amit te akarsz arra teljesen elegendő. Van elérhető rendes leírása több helyen is. Megvalósítani egyszerű, akár uC-ben is ahol kevés RAM-od van.
Fejlesztést meggyorsítja, hogy tudsz venni kész eszközöket is. Persze legyárthatsz Te is majd akármilyen érzékelőt, ami akár nem is találsz készen, vagy drágának találsz.

Van még sok protokoll, de sajátot is írhatsz.

A megvalósítást célszerű ha tervezés előzi meg, azt pedig kutatás.
Most valahol a kutatás részénél tartasz. Próbálgathatsz is hardvereket, protokollt, szoftvert. A kutatás alatt szerzett információkat jól felhasználva megtalálhatod ami neked kell.

A CAN mint átviteli közeg talán arra lenne jó, hogy az Ethernetet kiváltva (miért is váltanád ki?), az RPi-k egymással itt kommunikálhatnának.
De, csinálhatsz szenzorokat amiben van 1-1 kis számítógép-->uC és ezek CAN-en kommunikálnak.

Köszönöm a konkrétumokat.

Igen, a kutatásnál járok, és azért kérdezek különösen sok hülyeséget, mert ki akarom zárni a kevésbé optimális, vagy indokolatlanul nagy erőforrást igénylő megvalósítást. Értem ez alatt konkrétan nem érzem a szükségét, hogy új kommunikációs protokollt, új interfészt, vagy bármilyen nem létező szabványt dolgozzak ki. Lehetne, ha több időm lenne, ezt csinálnám, és éveket töltenék ezeknek a megtervezésével, de most inkább kész elemekből szeretném összelegózni a megoldást, hogy már a kábelezés csillagpontosan adott.

Nekem így túlzásnak tűnik, hogy mindenhova RPI-t rakni helyiségenként, ezért tetszene az, ha csak a szenzorok lennének ott, valamilyen átalakítóval.

Amit lentebb írtam RJ45/Etherneten működő I2C, SPI, I2C/SPI-s eszközökkel megvalósítható szerinted ez? Mert kb 10 USD/modul, RJ45, csak a szenzorokat kell rátenni, könnyűnek tűnik a kiépítése, üzemeltetése.

Sakk-matt,
KaTT :)

A mindenhova rpi és a valamilyen átalakító között megfontolható megoldás (többen írták már) egy uC az adott helyeken.
Lekezelheti a szenzorok rövid hatótávú I2C vagy SPI buszát, és normális buszon beszélhet "a" pivel.

Igen, ebben az irányban keresgélek, most épp az Ethernet-I2C/SPI irányban.

Sakk-matt,
KaTT :)

Idő-Ár-Érték-Fejlesztési idő változókat nézve valószínű az lesz a legolcsóbb ha RPi-re aggatsz rá mindenféle szenzort I2C esetleg SPI-on. Ezeket az RPi-ket pedig etherneten keresztül eléred.
Így gyorsan cserélhetsz szoftvert, és mindenféle dolgokat kialakíthatsz a helyszínen is.

Ha sok szenzor kell akkor a szenzort vagy szernzorokat 1-1 uC-re tenném, talán ESP32 a leggegyszerűbb, van vezetékes ethernet illesztésre is lehetőség, van olimex-es demo board. Erre már speciálisabb szoftver kell.

Ha még tovább megyünk akkor pl. PIC-ből van olyan ami ethernetes, csak a trafó és csatlakozó kell rá. Ebbe már még speciálisabb szoftver kell, itt már a phyton, java és hasonló dolgok szóba sem jöhetnek. Kevés RAM és pl. 20MHz processzor.

Tehát Ethernet-I2C úgy érhető el hogy:
Ethernet--[X]--I2C
Az [X] pedig lehet:
-RPi
-ESP32
-Arduino + ethernet board
-PIC ethernettel pl.: PIC18F97J60

És még egyszer, MODBUS akár etherneten akár RS485-n, vannak már kész érzékelők.

pont ugyanigy latom.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Ami kimaradt az [X] listából és neked jó lehet:
- Orange Pi Zero
Ez is egy SBC, persze más SBC-k is szóba jöhetnek.
Azért Orange Pi Zero, mert:
- Olcsó. (az 512MB-os kevesebb mint 5.000 HUF)
- Lehetséges valami PoE szerü. Vigyázz nem rendes PoE, ez 5V-os!!!
- A 24/48V-os PoE megoldható külső DC/DC konverterrel, board-on forrasztgatással.
- Van WiFi
- Van SPI flash, amiből tud bootolni akár teljes kicsi rendszert
- Lehet microSD-ről nagyobb rendszert is indítani
- Van rajta I2C, UART, SPI, USB, és egyéb portok tüskés részen.

Ezt minden szenzor egységbe belerakod. Teszel rá olyan szenzort amit szeretnél, pl. I2C-n. Valami értelmes adattá konvertálod helyben a szenzor adatát, majd az tovább megy hálózaton a FŐ eszköz felé.
Van rajta elég GPIO, szóval akár még egy kis termosztát vagy hasonló dolog is megoldható vele.

Szia, köszönöm a javaslatot, ismerem az Orange Pi szériát, de nekem nem merült fel, hogy használjam.

WiFi felesleges rajta, mert UTP kábelen akarok kommunikálni.

POE-ra ilyet raknék:
https://www.amazon.com/UCTRONICS-PoE-Splitter-Gigabit-Raspberry/dp/B07CNKX14C

Ha már ezzel csinálnám, akkor úgyis NFS-ről boot-olnék a NAS-ról.

Ezzel is az a bajom, hogy ez egy SBC, és nekem elég lenne egy olyan kis modul, ami RJ45-ön tovább viszi az I2C/SPI szenzor adatokat, és ennyi. Szerintem "túl jó", túl sok mindent tud egy ilyen lebutított RPI, mint amit csinálni kell.

Nem lehetséges, hogy egy RPI 3B+ lekérdezzen 3-5 RJ45-re kötött modulon át 20-30 szenzort 1-3 percenként? Ez túl sok lenne? Vagy miért mindenki az SBC irányba akar terelni, amikor helyiségenként 1-3 szenzort akarok csak lekérdezni, például hőfok szenzort? Azt én is értem, hogy azzal is lehet, sőt, azzal biztosan lehet, de azt gondolom, hogy van egyszerűbb, kevesebbet fogyasztó alternatíva is, mint hogy helyiségenként legyen egy SBC.

POE kiegészítés:

https://linux-sunxi.org/Xunlong_Orange_Pi_Zero#Powering_the_board

"By soldering zero ohm resistors to R29 and R358 passive PoE providing 5V could be used to power the board. Note that 5V won't work over large distances (greater than ~4m) since cable resistance is too high and the voltage will drop.

It's also possible to solder a buck converter between the R29 pads (PoE+ to 5V VBUS) and R358 (GND) so that passive PoE with the higher voltages (24V or 48V) can be used. The buck converter is used to step the input voltage (24/48V) down to 5V.

If you plan to use a buck converter at higher voltages, remove R135/R136 (75 Ohm) as they will dissipate a lot of heat and may burn out! See the picture on the right and below in the gallery for which resistors to remove."

Ha jól sejtem ha ilyet használok:

DSLRKIT Active PoE Splitter Power Over Ethernet 48V to 5V 2.4A Compliant IEEE802.3af
https://www.amazon.com/DSLRKIT-Splitter-Ethernet-Compliant-IEEE802-3af/dp/B01DOSOCEE

Akkor a POE-s UTP kábelen jön az áram 4 eren (24V?) és a 100 mbites hálózat 4 eren, ez az eszköz szétválasztja és leveszi az áramot, majd 5V-ra alakítja és USB-n rádugom az Orange Pi Zero-t. Az eszközből kijövő RJ45 pedig sima 100 mbites hálózat, POE nélkül.

Sakk-matt,
KaTT :)

Ide válaszolok, közben lentebb is beleolvastam amiket írtál.
Azért ezt javasolnám neked mert valószínűleg az ESP32-n vagy arduino-n elvéreznél a sw részénél. Azért egy 8MHz-es és kevesebb mint 1MB RAM-al lévő uC-t másabb kicsit programozni mint egy operációs rendszeres akármit. Talán a másik véglet egy 8 magos gép lehetne csillió RAM-al, és futtatna valami JAVA / .NET szutykot. Ha pedig lassú lenne azt mondaná a fejlesztő hogy kell még CPU és RAM.

Nem bonyolult amugy egy ESP32 programozása sem, de ott a kommunikációs réteget is programoznod kell. Szóval hogy IP címet kapjon. Lehet nem csak 1-2 function-t kell meghívni meg ilyesmi.
Ezzel szemben megcsinálhatod linuxra akár valami script nyelven is az eszközöd programját. Sokkal gyorsabban, hamarabb van sikerélményed.

A PoE cuccok jónak tünnek. A bemásolt részt én is láttam, erre hívtam fel figylemedet, hogy bedugod PoE switch-be közvetlen miután aktiváltad a 2db 0 ohm-os ellenállással a funkciót és volt-nincs, mert kijön a működtető füst.

ESP32 olimex Ethernet PoE board-ból is ki lehet indulni. De amíg a linuxos megoldással 1 nap alatt megcsinálod az illesztést addig az ESP32-vel, ha eddig ilyet nem is láttál, akkor hetek lesznek. A topicból megismerve téged, az orangePi-t válaszd. Vegyél vagy 2db-ot és kösd rá a szenzort, kérdezd le helyben, majd csinálj hozzá valamit hogy távolról is elérhesd.

Ha tovább viszed a dolgot, akkor csinálhatsz nagyon kicsi rendszert alá, ami már beférhet az SPI FLASH-be is, akkor nem kell microSD vagy NETBOOT. De az SPI FLASH-be mehet a NETBOOT loader és eszköz config is.

Rövid idejű fejlesztés alatt szenzorokat kérdezhetsz le, vagy vezérelhetsz eszközöket.

Ha stabilabbra és kevesebbet fogyasztóra akarod akkor jöhet az ESP32, Arduino+Netboard, PIC-ethertnettel. De arra már egy működő protokollt kell majd átültetned, mert már SBC-n módosítgattad a programodat naponta, finomhangoltad és kitaláltad hogy működjön.

Persze ha nagyon sok időd van, fejleszthetsz magadnak egy megfelelő áramkört amit akár sziliciumra is megtervezed, legyártatod. Na abban nem lesz csak az amit te akarsz.

Attól hogy van az ESP32-ben BT és WiFi, és amugy nincs közvetlen ethernet csatolója, csak MII RMII, amire kell PHY csip (de szép szó), nem kötelező használni. Ahogy orangePi-n sem a WiFi-t, USB, vagy akármit amit nem szeretnél. Nem kell inicializálni nem kell semmit tenni vele. Viszont ha mégis kellene nagyon jó lesz hogy kaptál vele "ajándékba".
Régebben egy uC-n 2 UART-ért is ölni tudott volna az ember. Most meg CAN, UART, BT, WiFi, ethernet, LoRA, stb... és csak pislog az ember hogy egy 3x3mm-es akármi az egész.

Elgondolkoztam azon is, hogy miért írok.
Talán az a dolog volt amikor már nem bírtam magamban tartani, amikor láttam hogy nagyon nagyon más irányban jársz és megveszel majd egy raklap lomot, de működni sosem fog. A legjobb pedig az lesz benne, hogy nem fogod megérteni miért nem megy.
Ha SW-ben vagy jó, akkor menj abba az irányba, szóval orangePi.
Ha programoztál már uC-t vagy szeretnél akkor ESP32, arduino, PIC. Ide a "normál" PC programozás nem lesz jó.

"Azért ezt javasolnám neked mert valószínűleg az ESP32-n vagy arduino-n elvéreznél a sw részénél."

Én úgy mondtam volna ezt, hogy biztosan meg tudnám csinálni, csak a ráfordított idő miatt nekem már nem éri meg, mert ez nekem egy egyszeri projekt jelenleg, amivel ha készen leszek, szeretném használni. Van ASM/C múltam, regiszterek, IRQ, stb, de már nem friss ez a tudás és nem akarom ezt frissíteni. Tehát alapvetően a lényege az, amit írtál, hogy nem akarnám sw részét megcsinálni elsőre biztosan. Aztán ki tudja, ha annyira zavar az RPI overhead-je az ESP32-es megoldáshoz képest, lehet, hogy újracsinálom ESP32 alapon a szenzorok kezelését egyszer... :)

"Ezzel szemben megcsinálhatod linuxra akár valami script nyelven is az eszközöd programját. Sokkal gyorsabban, hamarabb van sikerélményed."

Így van, én ezt az utat választom inkább, mert ezekben friss a tudásom.

"A topicból megismerve téged, az orangePi-t válaszd. Vegyél vagy 2db-ot és kösd rá a szenzort, kérdezd le helyben, majd csinálj hozzá valamit hogy távolról is elérhesd."

Igen, bevallom, hogy ez a szenzorokhoz RPI-t választás picit csalódás / kudarc, mert azt tippeltem, hogy egy RJ45-I2C átalakítóval pikk-pakk megoldom 1 RPI-vel, de miután jobban beleástam magam az általatok felvetett kihívások megvalósításába, annak fényében pedig észszerű döntés, hogy egy gyorsabban megvalósítható megoldást választok. Igen, meg lehetne csinálni RPI-vel, csak a ráfordított időm nem éri meg nekem.

"Ha tovább viszed a dolgot, akkor csinálhatsz nagyon kicsi rendszert alá, ami már beférhet az SPI FLASH-be is, akkor nem kell microSD vagy NETBOOT. De az SPI FLASH-be mehet a NETBOOT loader és eszköz config is."

Igen, már az Orange Pi Zero netboot-ját néztem délután, az lesz.

"Ha stabilabbra és kevesebbet fogyasztóra akarod akkor jöhet az ESP32, Arduino+Netboard, PIC-ethertnettel. De arra már egy működő protokollt kell majd átültetned, mert már SBC-n módosítgattad a programodat naponta, finomhangoltad és kitaláltad hogy működjön."

Hát igen. Ez az, amit többen javasoltatok, és igazatok lett, köszönöm a segítséget. Elindulok RPI-vel, aztán meglátom hogy meg akarom-e csinálni ESP32 vagy más alapon.

"Persze ha nagyon sok időd van, fejleszthetsz magadnak egy megfelelő áramkört amit akár sziliciumra is megtervezed, legyártatod. Na abban nem lesz csak az amit te akarsz."

Erre egészen kicsi esélyt látok.

"Elgondolkoztam azon is, hogy miért írok.
Talán az a dolog volt amikor már nem bírtam magamban tartani, amikor láttam hogy nagyon nagyon más irányban jársz és megveszel majd egy raklap lomot, de működni sosem fog. A legjobb pedig az lesz benne, hogy nem fogod megérteni miért nem megy."

Hát, az én szemszögemből nézve nagyon jól tetted, mert kapkodtam a fejem balra-jobbra, több ezer RPI-hez illeszthető hardver adatlapját néztem végig az elmúlt hetekben, és jutottam több száz zsákutcába az elmúlt hónapokban. Ez a megoldás már az elején is felmerült, de azt gondoltam, hogy sokkal nyilvánvalóbban egyszerűbb is van. Van, csak mint fentebb írtam, ráfordított idő/eredmény mutató szempontból elsőre nem optimális. Hasznos volt, hogy ennyien rávilágítottatok. Nyilván ezzel is lesz meló.

Köszönöm még egyszer neked is, mindenki másnak is, aki hozzászólt, mert irányt mutattatok, bármennyire is önfejű voltam és bármekkora hülyeségeket is írtam / kérdeztem.

Akkor Orange Pi Zero jellegű hardveren indulok el a megvalósításban.

\o/

Sakk-matt,
KaTT :)

https://m.youtube.com/watch?v=55fqjw2J1vI

0:20 sectol

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Azért egy 8MHz-es és kevesebb mint 1MB RAM-al lévő uC-t másabb kicsit programozni mint egy operációs rendszeres akármit.

Azért már láttunk 1MHz-es i8080 alapú SZÁMÍTÓGÉPET 8-16kB memóriával. Az i8080 igen messze esett a RISC architektúrától. ;)

A 20db különféle szenzor lekérdezéséhez elegendő 30-100kHz órajel és 768b RAM. Néhány perces lekérdezéshez elméletileg kisebb sebesség is elég. Ennek a konstellációnak aprócska előnye, hogy a szenzorok és a processzor is <<100uA nagyságrendű áramforrásról elmennek. (0,0005W) Így aztán a villanyszámla is alacsony lehet. :-D

Persze ez csak az elmélet. A gyakorlatban az egész rendszer fogyasztása elérhetné az 1db wifi/ethernet csatoló fogyasztását is. (1W) :(

A legdrágább hardvert - a kábelt - már tartalmazza a rendszer. Legyen benne egy rpi is a brutális computing igény miatt! Ezek után csak a kábelt kell illeszteni a szenzorokhoz és a központhoz.

Szóval remegve várom a végkifejletet, amikor 2db Win10 munkaállomás és egy szerver lesz szenzoroként, amely rózsaszínű parabolaantennával végzi a kommunikáció. :0

"Szóval remegve várom a végkifejletet, amikor 2db Win10 munkaállomás és egy szerver lesz szenzoroként, amely rózsaszínű parabolaantennával végzi a kommunikáció. :0"

Nálam biztos nem... :)

Láttam Windows-hoz USB-s szenzorokat, szóval tényleg lehetne olyat is.

https://www.hackerboards.com/compare/251,139,88,114/

Ezek alapján az Orange Pi Zero-nál jobbnak tűnik az Orange Pi PC Plus

http://www.orangepi.org/orangepipcplus/

Különbség, ami számomra érdekes:
+ (1.2 Ghz )H2+ helyett AllWinner H3 (ARM Cortex-A7 (32-bit) 1.6GHz quad core) CPU
+ 512 MB helyett 1GB RAM
+ 8GB belső tárhely, még egyszerűbb a netboot / NFS (bár ez nélkül olcsóbb lehetne)
+ 1 Camera interface, bár elsőre erre sincs szükség, csak a ti jóslatotok miatt előny :)
+ Onboard mic
+ 26 helyett 40 GPIO PIN
- 1 I2C, így 2 helyett 1 van
+ 1 UART: 1 helyett 2
- fogyasztás: 600mA - 1.5A helyett 700mA - 2A
+ garantált működési hőmérséklet: -10 °C – 65 °C
- 3000 helyett 6500 Ft / darab, még mindig olcsóbb mint egy RPI 3B+ :)

Áramellátáshoz:
UniFi® Switch 16-150W 16 portos, 802.3af/at PoE+ or 24V passive PoE sharing

Aztán raknék az Orange PI PC Plus elé ilyet:
Active PoE Splitter Power Over Ethernet 24V to 5V 1A-2A Micro USB Adapter

És így kapja a dupla árnyékolt S/FTP kábelen az áramot is.

Így szerintetek jó lesz?

Sakk-matt,
KaTT :)

Különösen előnyös neked, hiszen I2C-n akarod kezelni a sok szenzorodat.
De legalább drágább is.

Még infó az Orange Pi PC Plus-hoz:

"It is also possible to power the device via GPIO pin header: connect +5V to either pin 2 or 4 (both are connected to DCIN test point) and GND to pin 6."

Közben a dokumentációja alapján ahogy nézem mégis 2 I2C busz van a PC változaton is, nem csak a zérón (3,5, 27,28 GPIO).
Tehát nem rosszabb.

Sakk-matt,
KaTT :)

"It is also possible to power the device via GPIO pin header: connect +5V to either pin 2 or 4 (both are connected to DCIN test point) and GND to pin 6."

Na, pont ez egy olyan részletkérdés, amit elolvasni sem érdemes.
Ha nálam a modul, megvan a környezete, úgyis nekem kell összedrótoznom. Tök mindegy, hová kell tenni a piros drótot, valahová úgyis rá kell forrasztani.

Mellesleg ezt már a legelső Pi-n is lehetett így csinálni, semmi újdonság nincs benne.

Ez talán olyan Unifi switch, ami nem önálló, csak a felügyeleti központon keresztül állítani, ott is korlátozott a beállítása. Nem javaslom. Talán EdgeSwitchet kell keresni (nekem van egy 24 portos eladóm... :-) ).
Unifi switch esetén van rá esély, hogy hangos lesz. A 24 portos legalábbis hangos.
PoE ellátást passzív PoE esetén megtudod csinálni PoE betáp panellel (hangtalan), 24 portos nem PoE switchek vannak ventillátor nélkül, szintén hangtalanok.

Köszi az infót, akkor még nézelődök.
Akkor a tápellátást inkább ilyen átalakítóval javaslod?

iCreatin Passive PoE Injector and Splitter Power over Ethernet Kit with 5.5x2.1 mm DC Plug for IP Security Camera
https://www.amazon.com/iCreatin-Passive-Injector-Splitter-Connector/dp/B00XMHDETM

Connectors Newest POE Adapter Cable Connectors Passive Power Cable Ethernet PoE Adapter RJ45 Injector + Splitter Kit 5V 12V 24V 48V
https://www.amazon.com/Connectors-Adapter-Ethernet-Injector-Splitter/dp/B07NPR1GLP

Itt 30-40 méter távot írnak, az elég.

Azonban ez tűnik a legjobbnak:

ANVISION Active Gigabit PoE Splitter Adapter with Multi-Size Tips, 10/100/1000Mbps IEEE 802.3af Compliant, DC 5V 9V 12V Power Output
https://www.amazon.com/ANVISION-Splitter-Multi-Size-1000Mbps-Compliant/dp/B01JCKHIGM/

Vagy TPLINK termékcsaláddal:

TP-Link Gigabit Ethernet PoE Splitter Adapter (TL-PoE10R)
https://www.amazon.com/TP-LINK-TL-PoE150S-Injector-Adapter-compliant/dp/B003CFATQK

És az Injector:

TP-LINK TL-PoE150S PoE Injector Adapter, IEEE 802.3af Compliant, up to 100 Meters (325 Feet)
https://www.amazon.com/TP-LINK-TL-PoE150S-Injector-Adapter-compliant/dp/B001PS9E5I?th=1

Továbbá 5 portos TPLink switch, 4 POE:
https://www.amazon.com/TP-Link-TL-SG1005P-Gigabit-Ethernet-compliant/dp/B076HZFY3F/

De lehet keresek egy sima 8 portos gigabites fanless switch-et, és poe injector/splitterrel oldom meg. Még van időm kitalálni.

Például:
D-Link 8 Port Gigabit Unmanaged Metal Desktop Switch (DGS-108)
https://www.amazon.com/D-Link-Gigabit-Unmanaged-Desktop-DGS-108/dp/B000BCC0LO/

Tehát az RPI tápot rádugom az egyik végére, hozzácsapja az UTP kábel üres ereire, majd ha a kábel elért az Orange Pi PC Plus-hoz, vagy hasonlóhoz, akkor ott a kábel szétválasztja a hálózati és a tápra, a tápot kirakja mint egy csatlakozó, amit az Orange Pi-be dugok, és kész.

Sakk-matt,
KaTT :)

Nem tudom, mennyi kütyüd lesz, de érdemes lehet rack-ben gondolkodni. Nem is feltétlenül szekrényben, de legalább valami rack formátumú fali tartóban (https://www.kabelfutar.hu/101/24/19-fali-rack-szekrenyek/4u-520x300-19-fali-tarto). Különben őskáoszként vagy kiterített terepasztalként (sok hely) fog kinézni.

PoE (feszültségeket stb nem néztem, csak formátum vonatkozásában):
- központi részhez ilyet javaslok: https://www.amazon.co.uk/WS-GPOE-12-1U-gigabit-Poe-injector-separately-black/dp/B00ENO3HT0
a nem PoE switch-ből ebbe vezetet az utp-t, majd ebből megy a patch panelbe
- végpont részhez olyat, amit linkeltél

Így a központi részed rendezett formát tud ölteni. Én ha lehet passzív PoE-t használok a fentiek miatt, de van egy talán ~8 portos aktív PoE switch-em is néhány kütyünek. Minden rack-es. Én csak menedzselt switchet használok, az automatizálásnak külön VLAN-ja van, kameráknak másik, felhasználói vackoknak harmadik stb.

Helyes :Đ
Büntessük rackszekrénnyel, mert nem akar wifit használni.

Én eredetileg is egy rack szekrény jellegűben gondolkozom, szóval köszönöm a megerősítést.
Fizikailag külön switch-re rakom az egész otthonvezérlést, nem lesz internet kapcsolat rajta, csak belsőleg lesz elérhető.
Köszi az ajánlásokat. Miben jobb egy ilyen, mintha POE-s switch-et vennék? Vagy miben jobb, mintha a linkelt injector / splittert használnám?

Sakk-matt,
KaTT :)

PoE switch kb 8 portig van, aminek nincs ventilátora (azaz nem hangos). Nem PoE switch-nél tipikusan 24 port a limit. 8 port nagyon gyorsan megtelik. Ezenkívül sokkal olcsóbb a sima, mint a PoE switch. A menedzselt switch-nek több előnye is van, többek között gazdaságosabb a helykihasználás: nemcsak automatizálási eszközt dughatsz bele, hanem mást is, VLAN-nal megoldod az elzárást. Egyébként célszerű az internet kapcsolat (ez így nagyon pongyola, de talán érthető), mert akkor távolról is rá tudsz nézni.

A rack-es PoE injektornak az az előnye, hogy csak egy betáp van, azaz sokkal kevesebb konnektor+kábel kell. Ezenkívül esztétikusabb, könnyebben átlátható/kezelhető.

Köszönöm az infókat. Mivel lehet, hogy a multiroom audio miatt amúgy is lesz RPI a helyiségben, így újra tervezem a koncepciót, és lehet, hogy a zenelejátszó kezeli a szenzorokat is, de van olyan, ahol nincs zene, csak szenzorok, tehát nem felesleges az Orange Pi Zero vagy PC PLUS irány, csak lesz más is. További infó, hogy a multiroom audiós RPI az erősítőtől kapja az áramot GPIO-n, az erősítőnek pedig kell kb 80 watt, tehát ezt nyilván nem POE-n fogom átvinni, mert az más sok, hiszen infóim szerint kb 15 watt tud csak átmenni: 44VDC + 350 mA. Szóval mint látod, egészen sok kihívást találtam... :-) Emlékeztetőül: nekem ez tetszik és jó ezekkel foglalkozni. Nem, a világűrbe nem szeretnék menni... :-)

Elvből nem VLANnal akarom megoldani a hálózat szétbontását, hanem fizikailag külön hálózattal (egy 8/12/16 portos switch-en a lakásvezérlés, szünetmentes tápon, és egy külön switch a többi célra (ami lehet később tovább lesz bontva) ). Ennek egyrészt az az oka, hogy a tervezett RPI-s hálózatnak elég lehet a 100 mbit is, tudom, már alig van csak 100 mbites switch, mert pár ezer Ft a gigabites is... :) Másrészt nekem az jó érzés, hogy az összes RPI csak UTP kábelen kommunikál, le lesz tiltva minden BT/WiFi és vezeték mentes kommunikáció, kivéve a klímának az IR, és nincs internet kapcsolata a már élesben használt eszközöknek azon a hálózaton. Mindenkinek vannak hülyeségei... Tudom egy nagyobb menedzserelhető switch-en VLAN-ozással is meg lehet oldani, VPN használattal vagy routing-gal is lehetne megoldást a hálózatok szétválasztására, azonban elvből nem akarok ilyen szoftveres megoldást rá. Mert így érzem... :-)

Sakk-matt,
KaTT :)

Kicsit más szemmel nézzük ezt a dolgot, de ez nem baj. Pedig hidd el :-) nem rossz az, hogy távolról ki tudod nyitni a kaput. (egyébként egy integrált busz rendszer esetén ez is nagyon klassz: garázs és bejárati kapunak dedikáltam kapcsolót, így arról is ki tudom nyitni, nem kell távirányítót keresgélni) Ha meggondolod magadat, nem nagy dolog végül összekötni a két rendszert.

A multiroom audiot miként csinálod? Az RPi a beépített hardverrel "készíti" a hangot, vagy valami külső hangkártyával? Szoftveresen miként oldod meg, valami streaming lesz? Miként fogod irányítani (mi szóljon)?

Persze hogy nem hátrány, ha ki tudom nyitni távolról a kaput, de nem prioritás. Mindent ami fontos volt, központosítva van bekötve, így központból tudom kapcsolni és a helyi kapcsolóval IS. Az, hogy nem használom első körben a központi kapcsolást, egy dolog, de a lehetőség megvan. Elsőnek a LED-ek kapcsolását fogom megoldani impulzus kapcsolókkal: központba van kötve, és a fali erősáramú kapcsoló is a központban lévő impulzus relét kapcsolja, és automatizáltan is tudom kapcsolni, de az okos otthon nélkül is működik (ha az impulzus relé is működik :) .

A multiroom audiót RPI alapon csinálom, azonban mivel passzív pár sztereó hangfalaim vannak (8 ohm, 20-100 watt erősítőre ajánlott) ezért ezekkel lesz megoldva:

JustBoom Amp HAT for the Raspberry Pi
https://www.justboom.co/product/justboom-amp-hat/

Full high quality audio – 192kHz / 32bit
2 x 55 Watt peak output at 8 ohms (2 x 30 Watt RMS)
Includes both a DAC and power amplifier – just connect to your passive speakers
Back-powers the Pi over the GPIO (with full HAT compliant protection) at 2.5A so only one power supply required for the whole system.
Plug and play compatibility for ease of use
Hardware and software volume control from your Raspberry Pi
Onboard, hardware jumpers for configuring mute and gain settings (jumpers could optionally be changed with switches)
Mute/enable with GPIO22 (this can be overridden by using jumper J4)
No soldering required
Compatible with Raspberry Pi A+,B+, 2B and the new 3B (and also compatible with the Raspberry Pi Zero, but we would recommend the JustBoom Amp Zero for this purpose)
Mounting hardware included
Optional IR receiver included in package
Unused GPIO pins still accessible via a populated extension header
The Raspberry Pi Amplifier is fully HAT compliant
Full driver support in Raspbian / NOOBS
Compatible with JustBoom Player / OSMC / Max2Play /RuneAudio / Volumio / Moode / PiCorePlayer / PiMusicBox / OpenELEC and others
JustBoom Player pre-configured software available on SD cards from various vendors

és, ami csak 6 ohm-ra javasolt, itt még nem dőlt el, mire kötöm:

Pi-DigiAMP+
http://iqaudio.co.uk/hats/9-pi-digiamp.html

Full-HD audio – up to 24-bit/192kHz playback
Up to 2x40w of crystal clear amplification (provides up to 2 x 40W stereo output to 6ohm speakers)
Pre-programmed EEPROM for auto configuration
Integrated hardware volume control (via ALSA)
Powers the Raspberry Pi from the Pi-DigiAMP+ power input
Linux driver support already delivered within Raspbian
Advanced ESD protection
Uses the digital I2S audio signals
Supports up to 24v input
Delivers full 2.5amp to the Pi, supports screens & USB devices in parallel
Full GPIO access with no soldering required
Fully built and tested Raspberry Pi accessory
Designed and manufactured in the UK

Fontos, hogy ez egyik sem megy az RPI4 hardverével még, csak ezekkel:

Raspbery Pi A+/B+, RPi2 AND RPi3+ it is not compatible with much older Raspberry Pi A and B Models

További infó, hogy 3B+ esetén recseg, ha az Ethernet gigabiten megy, mert USB-n keresztül megy az Ethernet (és maximum 300 Mbit, mert ennyi tud átmenni az USB-n) és ha azon olvasod a zenei forrást, zavarja a zenelejátszást. Ha Wifiről vagy SD kártyáról olvasod, nem recseg.
A megoldás, hogy lekorlátozod 100 Mbit Full Duplex-re az Ethernet kapcsolódást, vagy veszel 3B-t plusz nélkül, ami alapból csak 100-as Ethernetje van.
Az RPI4 esetén már ez javítva van (Ethernet nem az USB buszra csatlakozik és megy is 1000 Mbiten), csak még nem tudni, hogy megy-e.

Ez vonatkozik az összes ilyen külső erősítős cuccra.

Szóval elsőnek a Justboom AMP Hat lesz, mert az támogat 8 ohm-ot. Az Iqaudio pedig a második ami tetszik, az csak 6 ohm.

Ha esetleg kevés lenne a lehetőség, itt egy 2017-es gyűjtés az RPI-hez használható DAC/DAC+AMP/AMP-ról:

https://www.tech-knowhow.com/2017/06/raspberry-pi-audio-hats-hardware-attached-top-definitive-list/

1.1 Audio Injector
1.1.1 Zero Soundcard
1.1.2 Stereo Soundcard
1.1.3 Octo Soundcard – Cirrus Logic 42448 – 24/192
1.2 AudioPhonics
1.2.1 I-Sabre I-DAC ES9023 TCXO
1.2.2 I-Sabre AMP DAC – Saber ES9023 / 24/192 – Class D Amp 2x30W TPA3118
1.2.3 RaspDAC Kit – Special Mention
1.3 Fe-Pi
1.4 G2 Labs
1.4.1 BerryNOS 1543 Red
1.4.2 BerryNOS mini
1.5 HiFiBerry
1.5.1 DAC+ Light
1.5.2 DAC+ Standard
1.5.3 DAC+ Pro
1.5.4 DAC + Zero
1.5.5 Digi+ Standard
1.5.6 Digi+ Transformer
1.5.7 Digi+ Pro
1.5.8 Amp+
1.6 IQaudIO
1.6.1 Pi-DAC+ – TI PCM5122 – 24/192
1.6.2 Pi-AMP+ for Pi-DAC+
1.6.3 Pi-DACZero – TI PCM5122 – 24/192
1.6.4 Pi-DACZeroHP
1.6.5 Pi-Digi+ – Wolfson WM8804 – 24/192
1.6.6 Pi-DAC Pro – PCM5242 – 24/192
1.6.7 Pi-DigiAMP+ – TI TAS5756m – 24/192
1.7 JustBoom
1.7.1 Dac Zero 32/192 – TI PCM5121
1.7.2 Amp Zero 32/192
1.7.3 Digi Zero – 24/192
1.7.4 Digi HAT – 24 /192
1.7.5 DAC HAT – 32/192
1.7.6 Amp HAT – 32 /192
1.8 Collybia
1.8.1 Mamboberry
1.9 Orchard Audio
1.9.1 PecanPi Streamer / DAC
1.10 Pi 2 Design
1.10.1 502DAC – Pro Audio Shield – 24/192 – TI PCM5122
1.10.2 503HTA Hybrid Tube Amp – 24/192 – TI PCM5102A
1.10.3 Pi2Media
1.11 PiFi
1.12 Pisound
1.13 Pimoroni
1.13.1 pHAT DAC – 24/192 – TI PCM5102A
1.14 Raspyplay3
1.15 Other
1.15.1 Cirrus Logic Audio Card
1.15.2 Wolfson Audio Card – 24/192

Sakk-matt,
KaTT :)

Köszi, és a szoftver része? :-)

Kb sorrendben, multiroom-ot támogató megoldások:

https://volumio.org/

https://www.max2play.com/en/features/

http://www.runeaudio.com/

https://osmc.tv/

https://www.picoreplayer.org/

https://jriver.com/

https://moodeaudio.org/

Az első kettőt javaslom első körben.

volumio-nak vannak natív appjai is vezérléshez
max2play pedig kifejezettem multiroom támogatású

Konkrét megvalósítás lépésről lépésre:

https://www.max2play.com/en/2019/01/step-by-step-multiroom-audio-setup-with-max2play/

Justboom:
https://www.max2play.com/en/2019/01/budget-multiroom-audio-living-room/

Hifiberry:
https://www.max2play.com/en/2019/01/step-by-step-multiroom-audio-setup-with-max2play-the-kitchen/

IQAudio:
https://www.max2play.com/en/2019/02/step-by-step-multiroom-audio-setup-with-max2play-the-bedroom/

Hifiberry, Iqaudio, Justboom, kb az erősítős változatokat így raknám sorrendbe a támogatottság szerint.

Sakk-matt,
KaTT :)

Köszi szépen, első blikkre szimpatikusak. Elmentem, aztán ha valamikor felülvizsgálom a mostani rendszeremet (van 2 bosszantó jellemzője), ismét előveszem. (én most mpd-t használok - https://www.musicpd.org/ - , ezzel a részével nincs gondom, telefonról is jól vezérelhető).

Ezt nem ismertem, köszi. Mi az a 2 bosszantó? :)

Sakk-matt,
KaTT :)

A rendszer olyan, hogy a központban van egy logika, ami négy hangforrást el tud osztani N végpontnak. Az N végponton lehet választani a 4 hangforrás közül.
Ha van zene lejátszás, de sehol nincs megszólaltatás (minden végpont le van kapcsolva), akkor néha reccsen egyet 1-1 hangfal.
Van úgymond lokális bemenet: ha azon van hang, akkor a hangszórón ez szól, nem a központi 4 bemenet egyike. Ez sajnos automata, ha túl halk rész van, akkor úgy érzékeli, hogy nincs hang és lekapcsolja. Majd kell kis idő, mire visszakapcsolja, így kimaradhatnak részek.

Köszi az infót, ha másik rendszernél tapasztalok ilyet, megírom :)

Sakk-matt,
KaTT :)

Lazan kapcsolodik, nem akarom eroltetni a PoE-t - a Type 2 / Class 4 (802.3at, PoE+) 30W-ot tud kiadni (legrosszabb esetben, max. kabelhosszal szamolva 25.5W jon ki) - persze ez meg mindig nem eleg, de mar vannak eszkozok amik tudjak a 802.3bt-t, amit Type 4 eseten 100(!)W.

De megegyszer, en sem ebbe az iranyba mennek a helyedben ami az erosito taplalasat illeti :-)

/sza2

--
Digital? Every idiot can count to one - Bob Widlar

A zenei cuccok annyi mindenre érzékenyek, aminek egy része valós, vagy legenda, vagy csak szubjektíven hallható különbség, hogy itt nem szívatnám magam, hogy az erősítő POE-n menjen. Köszönöm azért.

Sakk-matt,
KaTT :)

POE switch:
https://www.ebay.com/itm/5-8-16-Ports-Network-Switch-10-100Mbps-Gigabit-LAN-POE-Ethernet-Hub-PC-Adapter/253740509493?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649
És legalább rack szekrény se kell hozzá.

"dupla árnyékolt S/FTP kábelen"
Kell is a dupla árnyékolás, mert olyan ipari környezetben használod, ahol a nagy elektromágneses zavarokat mindenképpen ki kell szűrni.

Köszi az ajánlást.

Igen, a dupla árnyékolás azért is jó, mert lehet, hogy végül az űrbe is ki fog repülni az épület, és készülnöm kell az erősebb sugárzásra... :-) Remélem amit ajánlottál switch, az is világűr kompatibilis! :-)
Azért lett ilyen kábel, mert ez így biztosan nem lesz korlátozó tényező a későbbi tervekben.

Sakk-matt,
KaTT :)

Még egy kiegészítés:

I2C buszon 20 méterig jó ez, 5 ezer Ft/modul, 10 ezer, mert kettő kell / helyiség:

Active I2C Long Cable Extender P82B715 Module
https://sandboxelectronics.com/?product=active-i2c-long-cable-extender-p82b715-module

I2C buszon 300 méterig jó ez, 5 ezer Ft/modul, 10 ezer, mert kettő kell / helyiség:

PCA9600 Differential I2C Long Cable Extender with Buck Convertor
http://sandboxelectronics.com/?product=pca9600-differential-i2c-long-cable-extender-with-buck-convertor

I2C buszon 300 méterig jó ez, RJ45 csatlakozóval, 5,5 ezer Ft/modul, 11 ezer, mert kettő kell / helyiség:

https://sandboxelectronics.com/?product=pca9600-differential-i2c-long-cable-extender-with-buck-convertor-and-rj45-adaptor

Jelen tudásom alapján ezzel csillagpontosan 1 darab CAT6A vagy CAT7A kábelen 6(esetleg 8) eret használva át tudom vinni a 20 méterre lévő helyiségekbe a jelet, és ha külön I2C busz lesz mindegyik helyiség esetén, akkor nem lesz I2C ID ütközés és kész.

és még:

http://www.pridopia.co.uk/pi-23017-8-v2.html

Azt nem tudom, hogy ez működhet-e a gyakorlatban is, én csak próbálom összerakni kész elemekből.

Sakk-matt,
KaTT :)

I2C buszon 20 méterig jó ez

Én a helyedben messzire kerülném az I2C-t ilyen távolságokon. És a CAN-t is elfelejteném, hacsak nincsenek natív módon CAN-t beszélő szenzorjaid (amik kb. akkor lehetnének, ha autóba tervezett dobozokat használsz).

Minden szenzorcsoport mellé egy pici mikrokontroller, az beszélget a szenzorokkal I2C-vel, SPI-vel, vagy ahogy jólesik (ugye sima analóg jelet adó szenzort is lehet használni ilyen esetben, csak olyan mikrokontrollert kell választani, amiben van ADC), az UART-jára egy RS485 transceiver, és lehet őket felfűzni az 485 buszra. Pár száz Ft egy ilyen mikrokontroller...

Ezt mesélheted egy szoftveresnek, aki egyetlen raspivel akarja feldolgozni az egészet, a többi csak drótozás.

Azt olvastam, hogy egy adatbuszon 120+ szenzor is lehet és akár 1km távolság is, én bőven ezeken belül vagyok.

Egy szóval sem mondtam, hogy ragaszkodom a kizárólag 1 RPI-hez, csak azt sejtem, hogy okosan megtervezve, megfelelő adatbuszon nem kellene gondnak lennie a 20-30 szenzornak sem, főleg, ha kb 1-5 percenként akarom csak lekérdezni ezeket.

Már induláskor, mindenféle segítség nélkül is meg tudtam volna csinálni, hogy mind a 8 helyiségbe rakok 1-1 RPI-t, rá I2C/SPI buszon a szükséges 1-3 szenzort (Pimoroni Breakout-okból:

Breakout Garden for Raspberry Pi (I2C + SPI) (6 slot)
https://shop.pimoroni.com/products/breakout-garden-hat-i2c-spi

Breakout Garden pHAT (3 slot, I2C)
https://shop.pimoroni.com/products/breakout-garden-phat

Ebbe szenzor:
BME680 Breakout - Air Quality, Temperature, Pressure, Humidity Sensor
https://shop.pimoroni.com/products/bme680-breakout

És további 50+ szenzor:
https://shop.pimoroni.com/collections/pimoroni-breakouts

Rádugom a pHAT-ot az RPI-re, bele a szenzorokat, felrakom a szükséges Raspbian kernel modulokat, bekapcsolom a config-ban amit kell, és megy is.
),

majd UTP-n (akár POE-vel) egy switch-be (POE-s switch-be) kötöm mind a 8 RPI-t, és egy központi RPI-vel lekérdezem a szenzorokat, vagy a 8 RPI eleve lekérdezi és kiírja valamilyen formátumban, adatbázisba teszi, RRD-be / InfluxDB-be / Granába / bármilyen monitoring vagy egyéb adatbázisba teszi, majd onnan kiolvasom X időnként a központi helyről.

Csak hiszem azt, hogy adatbuszon is meg lehet oldani a kommunikációt valahogyan a szenzorokkal, csillagpontosan.

Veled kapcsolatban nem tudom eldönteni egyértelműen, hogy még nem döntötted-e el, hogy segíteni akarsz nekem vagy sem, és azért válaszolsz így, vagy hozzám hasonlóan te sem tudod a megoldást, csak annyival bölcsebb vagy, hogy pár nyilvánvaló hibát felismersz, és ez már elég mély tudás hozzá, hogy mondd, hogy nem jó úton vagyok.

Úgy vagyok veled, mint az a gyerek, akit magára hagyottan nevelnek szülei: ha bántják a szülők a gyereket, a gyerek annak is örül, mert legalább abban a kis időben is foglalkoznak vele és látja a törődést. Még ha nem pozitív, akkor is legalább van valami. :-)

Komolyra fordítva a szót: pár száz, vagy pár ezer hasonló útkeresés a részemről, és kizárom a rossz megoldásokat, csak lesz olyan, amire még te is azt mondod, hogy ****, de nekem jó lesz és működhet is akár, ha megépül. :-)

Sakk-matt,
KaTT :)

Megtaláltad :)

" vagy hozzám hasonlóan te sem tudod a megoldást, csak annyival bölcsebb vagy, hogy pár nyilvánvaló hibát felismersz, és ez már elég mély tudás hozzá, hogy mondd, hogy nem jó úton vagyok."

Őszinte kérdésre őszinte válasz.

Szia, köszönöm az infót.

"csak olyan mikrokontrollert kell választani, amiben van ADC"

ADC alatt az analóg - digitális konvertert, átalakítót érted ugye? Tehát hogy úgy viszi át az adatot, hogy a feszültséget digitális számmá alakítja, tehát például úgy van beállítva, hogy ha nincs feszültség, akkor a digitális érték 0, ha 4V a feszültség, akkor meg 128 az érték, 2V esetén 64. Stb.

És a szenzorok is az adatot, amit küldenének ők digitális számként adják ki, majd át kell alakítanom analóg jellé (D-A), amit valahogy adatbuszon az RPI közelébe viszek, és ott újra az analógból digitális jel kell (A-D), amit feldolgozok. RPI esetén nagyon sokat olvastam arról, hogy 5V helyett 3V kap a MAX485/RS485 és úgy is megy, máshol pedig megoldották RPI esetén is az 5V-ot. Ez nem tiszta, hogy melyik út a jobb és miért.

Igen, többen az RS485 irányába terelnek.

Amit itt ebben a témában írtam konkrét termékeket:

https://hup.hu/node/164703#comment-2365861

Felsoroltam szenzorokat, ezek közül melyiket javasolnád, vagy ha nem ilyet, akkor konkrétan milyet?

Próbáltam a bekötést összerakni itt:

https://imgur.com/QCmTF9s

Ez így jó irány, vagy mit mire cseréljek?

A bekötés így jó lesz?

Meg tudnád írni első körben, hogy szerinted milyen konkrét termékekkel lehet megoldani, hogy RPI 3B+ -ra rákötve, csillagpontosan 20 méter távolság maximum és a 10 darab SPI/I2C-t támogató szenzor közé mit tegyek, úgy, hogy I2C-n a szenzor normál esetben az I2C ID-je ütközne, és a szenzor csak 2 ID-t tud felvenni egy I2C buszon (BME680 #76 vagy #77 I2C ID-n tud csak menni). Vagy hogy legyen SPI busz, vagy az a megoldás, hogy több I2C buszon lesz, 2 szenzoronként, vagy valamilyen módon más I2C ID-t tudok adni a szenzornak? Nekem mindegy, csak minél egyszerűbb, kevesebb alkatrésszel, és működő megoldás legyen, nem ragaszkodom semmilyen technológiához ezeken belül.

Sakk-matt,
KaTT :)

"És a szenzorok is az adatot, amit küldenének ők digitális számként adják ki, majd át kell alakítanom analóg jellé (D-A), amit valahogy adatbuszon az RPI közelébe viszek, és ott újra az analógból digitális jel kell (A-D), amit feldolgozok. "

Mi a lófasznak alakítod vissza analóggá?
Adatbuszon viszed az analóg jelet? Mi van?
Gondolkodni szoktál?
Éjjel inkább aludj, jobbat tesz.

ADC alatt az analóg - digitális konvertert, átalakítót érted ugye? Tehát hogy úgy viszi át az adatot, hogy a feszültséget digitális számmá alakítja, tehát például úgy van beállítva, hogy ha nincs feszültség, akkor a digitális érték 0, ha 4V a feszültség, akkor meg 128 az érték, 2V esetén 64. Stb.

ADC alatt azt értem, hogy a mikrokontroller egy analóg jelet kap, és abból ő csinál digitálisat. A legtöbb buta szenzor analóg jelet ad ki magából, tehát valamit még bele kell rakniuk a gyárban, ha I2C/SPI/stb. interfésszel rendelkező szenzort akarsz venni. Ha amúgyis van egy mikrokontrollered a szenzor mellett, akkor arra akár analóg kimenetű (buta) szenzorokat is köthetsz. Ha nincs ilyened, akkor csak digitális kimenetű szenzorokat tudsz használni (mert az analóg jelet bazi nehéz messzire szállítani), mondjuk az I2C-t is ultraszopás messzire vinni, a SPI egy fokkal jobb.

És a szenzorok is az adatot, amit küldenének ők digitális számként adják ki, majd át kell alakítanom analóg jellé (D-A)

Nem, mert az a cél, hogy digitális jelet szállítsál.

Meg tudnád írni első körben, hogy szerinted milyen konkrét termékekkel lehet megoldani, hogy RPI 3B+ -ra rákötve, csillagpontosan 20 méter távolság maximum és a 10 darab SPI/I2C-t támogató szenzor közé mit tegyek, úgy, hogy I2C-n a szenzor normál esetben az I2C ID-je ütközne, és a szenzor csak 2 ID-t tud felvenni egy I2C buszon (BME680 #76 vagy #77 I2C ID-n tud csak menni). Vagy hogy legyen SPI busz, vagy az a megoldás, hogy több I2C buszon lesz, 2 szenzoronként, vagy valamilyen módon más I2C ID-t tudok adni a szenzornak? Nekem mindegy, csak minél egyszerűbb, kevesebb alkatrésszel, és működő megoldás legyen, nem ragaszkodom semmilyen technológiához ezeken belül.

a) egy vagy több Pi
b) ezekre valami RS485 transceiver, amin keresztül RS485 interfésszel fog rendelkezni a Pi
c) az RS485 busz topológia, ergó valahogyan a pontjaidat vagy egy, vagy több RS485 buszra fel kell fűznöd - nyilván az is opció, hogy annyi RS485 pont-pont "buszt" építesz, ahány végpontod van, aztán mindegyiken csak ketten lesznek, a Pi transceivered, meg a végpont
d) végpontonként egy mikrokontroller, ízlés szerint (ha ilyen kész cuccokat akarsz, akkor elmehetsz az Arduino irányba pl., azokhoz van bőségesen tudás a neten), amin van UART (ez szinte mindegyiken van) - erre kell rákötni ott is egy RS485 transceivert, meg annyi és olyan interfész, amilyen szenzorokat kell tudni helyben kezelni - I2C/SPI/analóg bemenet/whatever

Ha több RS485 kapcsolatot akarsz egy Pi-re (mert több buszt építettél, hogy ne kelljen mindenkit egy buszra felfűzni), akkor meg kell oldanod, hogy több RS485 transceivert is ráköthess egyszerre - ilyet szerintem semelyik gyári RS485 interfész modul nem fog tudni, ergó építeni kell valami multiplexáló áramkört. Vagy maradsz az egy busz/Pi modellnél.

Köszönöm a választ és a korrekciókat.

Ebből csinálni fogok egy újabb ábrát, hogy megértsem jobban ennek a működését, kiépítését.

"Nem, mert az a cél, hogy digitális jelet szállítsál."
Miután elküldtem a válaszokat, kezdtem rájönni, hogy rossz volt a teóriám, amit leírtam.
Már egy ideje tudom, hogy jelet szállító adatbuszt / topológiát tervezni releváns szaktudást igényel több területen :)
Kis túlzással a szoftver tervezés az 1-2 dimenziós valami, a hardver tervezés meg 3 dimenzió, annyi mindenre kell figyelni :)

Amit lentebb írtam RJ45 - I2C/SPI modul mennyire megoldás erre, azon kívül, hogy nem 1-2 USD hanem 10?

Sakk-matt,
KaTT :)

> mert az analóg jelet bazi nehéz messzire szállítani

4-20mA koszoni elvan mar vagy 50 eve. 2 er, zavarvedett, meghibasodast (kabelszakadas) is jelzi.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Ha jól értem, nekem 2 féle átalakító kell.

1.: RPI-hez CAN busz kommunikációs modul, amivel az RPI eléri a CAN buszt.

2.: Több darab CAN busz - SPI átalakító, és az átalakítóra SPI-n kerül rá az 1-3 szenzor helyiségenként. Helyiségenként pedig 1-1 ilyen CAN busz - SPI átalakító.

Ide kapcsoló kérdés:

K1.: Ha egy helyiségbe odakötöm a CAN buszt, rá a kiválasztott CAN busz - SPI átalakítót, akkor onnan hány méter kábellel köthetem rá a szenzorokat és hány darabot SPI-n keresztül? Mint ahogy az SPI standard támogatja, vagy rövidebbet, mert gyengült jobban a jel, stb?

K2.: Ha azonos típusú szenzor van egy másik CAN buszon, ahol ugyancsak SPI van, úgy nem lesz ütközés, mint ahogy az I2C buszon lehet ütközés és gond, ha azonos az ID?

RPI - CAN busz adapter: ===============================

Ez tűnik a legjobb RPI - CAN busz adapternek:

https://i.imgur.com/dDZCCUA.jpg

RS485 And CAN Module
http://www.inno-maker.com/product/rs485-and-can-module/
http://www.inno-maker.com/wp-content/uploads/2019/04/RS485-CAN-HAT.pdf

* RS485&CAN Module is an industrial communication module for Raspberry Pi, on board 2*RS485 Bus and 1*CAN Bus communication interface via SPI interface.
* CAN bus and RS485 bus powered through separated isolation power module, signal between the transceiver and the controller is isolated , ESD protection for the communication port, ensure your raspberry pi can be used in more strictly industrial sites

1. Compatible with Raspberry Pi Zero/Zero W/2B/3B/3B+. Only a small amount of GPIO are used and the rest pins allow to work for other extended function
2. Power supply and signal isolation, Build-in surge and ESD protection.
3. CAN function, onboard CAN controller MCP2515 via SPI interface, onboard high speed CAN transceiver, onboard digital isolation ADUM1201BRZ, Communication Rates 20Kbps-1Mpbs can be programmed arbitrarily.
4. RS485 function, controlled via UART, half-duplex communication, supports automatic TX/RX control without programming, onboard SPI to RS485 SC16IS1752. Electrical data isolation ADM2483.
5. On board individual 120 Ohm terminal resistance, Impedance matching and guarantee the ability to drive.

Tudtok ennél jobban megcsinált RPI - CAN busz adaptert?
CANBERRYDUALISO V2.1 TWO CHANNELS esetleg előnyösebb, az RTC-n kívül?

Ez a kettő között mi a különbség, az ISO itt mit jelent, mitől kerül másfélszer annyiba, és mi az előnye?

https://i.imgur.com/FtCY8c1.jpg

CANBERRYDUALISO V2.1 TWO CHANNELS
https://www.sg-electronic-systems.com/ecommerce/en/canberry/15-canberrydualiso-v21-two-channels.html

CANBERRYDUAL V2.1 TWO CHANNELS
https://www.sg-electronic-systems.com/ecommerce/en/canberry/12-canberrydual-two-v21.html

Az én esetemben van értelme 2 CAN buszt kihúzni 1 helyett? Jobb 2 rövidebb CAN busz, külön porton kezelve, mint 1 hosszabb?

CAN busz - SPI átalakítók ===============================

https://www.aliexpress.com/item/Waveshare-RS485-CAN-HAT-for-Raspberry-Pi-Allows-Stable-Long-distance-Communication-SPI-interface/32884453595.html
Features
* Raspberry Pi connectivity, compatible with Raspberry Pi Zero/Zero W/Zero WH/2B/3B/3B+
* CAN function, onboard CAN controller MCP2515 via SPI interface, with transceiver SN65HVD230
* RS485 function, controlled via UART, half-duplex communication, with transceiver SP3485
* Reserved control pins, allows to work with other control boards
* Comes with development resources and manual (examples in wiringPi/python)

Specifications
* Operating voltage: 3.3V
* CAN controller: MCP2515
* CAN transceiver: SN65HVD230
* 485 transceiver: SP3485

Ez 1,5 USD:

https://www.alibaba.com/product-detail/MCP2515-CAN-Bus-Module-TJA1050-Receiver_60755205627.html

MCP2515 CAN Bus Module TJA1050 Receiver SPI Module For Arduinos Raspberry Pi 51 AVR

MCP2515 Controller Bus Module TJA1050 Receiver SPI Protocol
1, Support CAN V2.0B specification, the communication speed 1Mb / S
2, 0 to 8-byte data field
3, The standard frame and expand the frame and remote frame
4. 5V DC power supply module, SPI interface protocol control
5, 120 ohm termination resistors. Impedance matching, ensure drive capacity, long-distance data transmission against signal radiation
6, Module size: 4.4cm x 2.8cm screw hole center spacing 23mm * 35mm
7, The working current: typ. 5mA, 1 microamp standby current. Except the power indicator
8, The working temperature: Industrial grade to 85 'C -40 'C
9, CAN controller chip: Microchip MCP2515, High speed CAN transceiver chip: NXP TJA1050

Jól gondolom, hogy nekem olyan lenne az optimális RPI-hez, ami 3,3VDC-vel megy, és nem 5?

Mint a fenti, csak forrasztani kell, 1,3 USD 2 darab:

https://www.aliexpress.com/item/2pcs-TJA1050-CAN-Controller-Interface-Module-Bus-Driver-Interface-Module-for-Arduino-EK2158/32976519920.html

Sakk-matt,
KaTT :)

Nem, nem jól értetted.
Kaotikus marhaság, amit írsz. (*)

1. CAN busz kommunikációs modul (*)
Világosan leírtam, hogy a CAN protokoll nem azonos a CAN busz meghajtó elektronikával.
CAN protokoll sehol sincs a rendszerben.
A feladat csak a hosszú kábel meghajtása, amit egy CAN meghajtó is el tud végezni.

2. CAN busz - SPI átalakító (*)
Az SPI-hez chip select kell, ami külön jel (vezeték) minden egyes perifériához.
A "CAN busz", amennyiben csak hardver protokoll nélkül, egyben SPI is, meg i2c is. ;) Ebben az esetben nincs mit átalakítani.

Nem is folytatatom...

Kezdjed úgy, hogy a sok nagyméretű kép helyett lerajzolod az elvi topológiát:

rpi --- kábel1 --- szenzor11, (kábel12) szenzor12...
|
--------kábel2 --- szenzor21, szenzor22...
|
--------...
stb.

Ezek után a világ összes és minden fajta moduljának megvásárlása és értelmetlen összekötése helyett, már lehet értelmes kérdést is feltenni, meg értelmes választ is adni.

Jó, akkor csinálok egy ilyen ábrát hamarosan. Köszönöm a segítséget.

Alapvetően azért nem csináltam még topológia ábrát, mert több minden bárhogyan lehet, az eredmény, a cél a fontos:

Cél:
- például 8 helyiségben lévő helyiségenként 1-3 szenzort (hőfok, pára, légnyomás, fény[lux], stb) (ami jelen helyzetben még I2C vagy SPI-s, de lehet bármi más is) rendszeresen lekérdezni

Kötöttségek:
- Ki van húzva csillagpontosan több 8 eres, 4 érpáros, árnyékolt / dupla árnyékolt CAT6A és CAT7A S/FTP kábel a helyiségekbe, amit tudok erre a célra használni, a csillagpont közepében lesz ami az egészet kezeli, vezérli
- Ha lehet, a kis fogyasztás, olcsó üzemeltetés miatt Raspberry Pi-ben gondolkozom, mint központi szerver (ami PXE boot és NFS-en fut NAS/Shared storage-ről).
- Ha lehet, ezeket a kábeleket akarom használni.

Ennyi. A többi, hogy milyen típusú szenzor lesz, ami hőmérsékletet mér, milyen buszon vagy interfészen kommunikál, az nyitott, a célnak megfelelőt keresem, ami RPI-vel tud kommunikálni. Az is nekem mindegy, hogy a szenzorok direktben csillagpontosan, vagy csak a helyiségek lesznek csillagpontosan bekötve, és hogy a helyiségekben a szenzorok sorban, párhuzamosan, vagy kiscica alakban lesz összekötve, ha úgy a legjobb, legyen úgy. Csak működjön.

Ha segít, lerajzom ezt szívesen. Nehezíti a rajzot, hogy 3 szenzorból nehéz kiscicát rajzolni.

Sakk-matt,
KaTT :)

Szerintem jobban jarsz, ha elobb valami altalanosabb architekturaval indulnal el, es utana pontositanad a reszleteket. Ha jol ertem, akkor eddig a kabelezessel vagy keszen, ez adott (meg a RPi).

En is RS485-tel indulnek el, 750 metert mar sikerult vele athidalni (foldbe asott telefonkabelen), epuleten belul talan birni fogja.
Ha csillagpontosat szeretnel, akkor vagy csinalsz olyan eszkozt, ami szetosztja, vagy megprobalod elviselni a visszaverodeseket (ilyen meretnel talan kibirja). Fogsz a sok erparbol 2-t, az egyik erparon lehet a kommunikacio, a masikon GND es a tap. Utobbi lehet mondjuk 12V vagy 24V, es a vegpontokban egy olcso DC-DC konverterrel csinalhatsz belole 5V-ot. (vagy ha nem eszik sokat, es eleg vastag a GND es a tap, akkor lehet kozvetlenul 5V is)

A csomopontba betehetsz a 485 konverter melle mondjuk egy-egy Arduinot (mini pro pl. $1.5 korul van, es tokeletes erre), erre kothetsz 1wire meg SPI/I2C szenzorokat, az UART meg mehet a 485 fele. Plusz van egy marek fennmarado pined GPIO-hoz. A node-ok tudhatjak, hogy milyen szenzor van rajtuk, a RPi meg foglalkozhat az atkuldott szam ertelmezesevel.

SW oldal: kitalalsz egy protokollt, a RPi kiad egy cimet, valami parancsot, utana veteli modba valt, es a megszolitott Arduinod visszakuldi amit mert. Aztan johet a kovetkezo node. Kiegeszitheto meg CRC-vel, minden egyebbel, akar meg a tavoli atprogramozas is megoldhato.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Az elmúlt időben próbáltam a szakmai hiányosságaim egy részét pótolni, az alapokat, stb.

https://www.amazon.com/Max485-Chip-RS-485-Module-Raspberry/dp/B00NIOLNAG/

Az RS485-ről ilyeneket olvastam az Amazonon:

"First things first: I haven't tested all five of mine, yet.

I bought these to wire up to a raspberry pi, to integrate into the RS-485 bus of my HVAC unit. It wasn't as 'easy' as I'd have liked it to be.
I think doing something like this with an arduino (I think I have one in this desk drawer somewhere...) would probably be a bit easier, but alas I haven't found an existing software stack for the HVAC system for an arduino. This being my first time working with RS485, I figured I'd be better off sticking with the 'standard' bits.

Some things to note, if you're trying to do what I did with a raspberry pi...

I found some wiring diagrams online, which were... more or less confusing as heck. Most of them had the DE and RE lines tied to GPIO pins (23/34 or bonded on GPIO18), and the DI and DO lines tied to the raspberry pi UART TX and RX (GPIO 14 / 15).

For starters, let's talk about the UART. You'll need to disable the serial terminal (in /boot/cmdline.txt) defined as a linux kernel param. In raspbian, there's the 'raspi-config' tool for this. BUT: you'll need to make sure that /boot/config.txt has 'uart_enable=1', for the /dev/ttyAMA0 driver to pick up the UART and publish the device.

Once you have your kernel params and config set properly, you'll probably try to connect your device to the 485 bus. If this bus happens to be your HVAC system, you may want to pick a comfortable day to work on this... because...

Upon bootup to a minimal raspbian install, those GPIO pins bound to DE and RE are both HIGH, putting the 485 device into transmit mode, and essentially interrupting the existing traffic on the bus. In the case of a Carrier/Bryant/Infinity HVAC system, this causes a 'bus communication error' and the entire HVAC will basically suspend all function until you remove your device from the bus. Fun times.

If all you want to do is read the bus traffic, you can wire the DE/RE pins to ground.
If you want to write to it in a controlled manner, we really ought not be using GPIOs to trigger this. There's been minimal documentation I could find on this, but what I have found mentions that I should tie the DE/RE to the TX pin of my UART and use a latch-type circuit (a 555 timer would be perfect for this) to drive the DE/RE pins high when TX goes high, hold them just long enough for the bit to transmit before resetting."

vagy:

"I use these with both Raspberry Pi and Arduino for DMX interfaces. They work very well. (caveat, I've never run DMX more than maybe 100ft with them, nothing like the 1300ft (400m) max of DMX512.

Would be 5 stars if the layout were saner: with VCC, GND, DI, DO, RE, and TE all at the same end on a 6 pin header, and A, B, and GND at the other end on a 3 pin header, instead of 4 and 4.

+ Has an onboard terminator
- If you don't need a terminator, you either have to desolder the chip resister, or shatter it out.
- Rather large for what it does.

Note: some people mention that this is a 5V only board, incompatible with the Pi, which has 3.3V GPIO. I've had success running them at both 3.3V and 5V (the one site that mentions using this board with a Pi for DMX shows it on 3.3V). This board has 3 inputs (2 enable and a data in) that have thresholds low enough for the swing of 3.3V logic, and a data output that doesn't seem to be able to harm a Pi serial input. If you're paranoid about that, add a simple voltage divider on the DO of the board."

De valahol azt írták, hogy nem production ready ez a cucc, maximum tesztelésre javasolják.

A MAX485 / RS485 helyett ez nem lehet jobb számomra, a lenti termékek?

#####################################################################################

DROK TTL to RS485 Adapter Module 485 to TTL Signal Single Chip Serial Port Level Converter 3.3V 5V Board with RXD, TXD Indicator Lights
https://www.amazon.com/DROK-Adapter-Module-Converter-Indicator/dp/B075V2NMV8/

"DROK TTL to RS485 converter wide operating voltage range is DC 3.0V-30V.
3.3V & 5V Signal: 3.3v with 5.0v power supply perfectly compatible; 3.3V with 5.0V signal perfectly compatible.
TXD & RXD Indicator: the TTL to RS485 Adapter is designed with Transmit Data indicator light and Receive Data indicator light, convenient for your monitoring.
Long Transmission Distance: transmission distance can be up to kilometers (test with 850 meters of 2 * 1.5 cable, it is recommended to use within 800 meters, more than 800 meters please add repeaters).
Special Function: the 485 bus is with lightning protection and anti-jamming function, with high EMC, EMI performance.

Parameters:
Operating voltage range: DC 3.0V ~ 30V
Operating temperature range: -40 ℃ to +85 ℃
Baud rate: 110 ~ 256000bps

Module Features:
1) the 485 bus is with lightning protection and anti-jamming function, with high EMC, EMI performance. When using for long-distance transmission in the field, the module EARTH side please connect to the ground, can achieve well anti-interference and lightning protection function; for indoor short-distance transmission, it cannot connect to ground.
2) with standard 2.54 pitch pin
3) with 120 ohm matching resistance, shorted R0 can be enabled to match the resistance, recommended shorted for long-distance transmission.
4) support multi-machine communication, the same network can connect at least 40 nodes.
5) can be hot-plugging, there will be no signal plug phenomenon.
6) using anti-jamming alignment and copper to prevent signal interference.

Package Including:
1x TTL to RS485 Signal Converter Module
1x 2.54 White Socket with 4P Lines
"

Itt az A+ és B- részeken felül van föld is.
Van rajta kis LED is, ez mondjuk a tesztelésnél jól jöhet.

Ugyanez az Alibabán 10 USD helyett 1,8 USD-ért:

TTL to RS485 Adapter Module 485 to TTL Signal Single Chip Serial Port Level Converter 3.3V 5V Board with RXD TXD Indicator
https://www.alibaba.com/product-detail/TTL-to-RS485-Adapter-Module-485_62102013923.html?spm=a2700.7724838.2017115.189.351b2b5cn2MEua

"Parameters:
Operating voltage range: DC 3.0V ~ 30V
Operating temperature range: -40 ℃ to +85 ℃
Baud rate: 110 ~ 256000bps

Module Features:
1. the 485 bus is with lightning protection and anti-jamming function, with high EMC, EMI performance. When using for long-distance transmission in the field, the module EARTH side please connect to the ground, can achieve well anti-interference and lightning protection function; for indoor short-distance transmission, it cannot connect to ground.
2. with standard 2.54 pitch pin
3. with 120 ohm matching resistance, shorted R0 can be enabled to match the resistance, recommended shorted for long-distance transmission.
4. support multi-machine communication, the same network can connect at least 40 nodes.
5. can be hot-plugging, there will be no signal plug phenomenon.
6. using anti-jamming alignment and copper to prevent signal interference.

Package included :

1x TTL to RS485 Signal Converter Module
1x 2.54 White Socket with 4P Lines"

Ez a termék oké lehet? Jobb, mint a csak A+ B- -os a célra?

#####################################################################################

Vagy másik termék:

DSD TECH SH-U12 RS485 to TTL 5V Board with MAX13487 Chip for Raspberry Pi Arduino and Other MCU
https://www.amazon.com/DSD-TECH-SH-U12-MAX13487-Raspberry/dp/B07B667STP

"With this RS485 to TTL board, you can quickly connect to the RS485 network, suitable for Raspberry Pi, Arduino,Robot and other MCU
Main chip is MAX13487 from MAXIM, High stability.LED indication for TXD,RXD, Power
With 15KV ESD protection and TVS overvoltage protection
Transmission rate up to 500Kbps, Support multi-machine communication, allowing up to 128 slave devices"

#####################################################################################

Még olcsóbban a fenti jellegű termék, LED nélkül:

Single-chip TTL to RS485 Module 485 to Serial UART Level Switch Hardware Automatic Control Flow
https://www.alibaba.com/product-detail/Single-chip-TTL-to-RS485-Module_60804302787.html?spm=a2700.7724838.2017115.176.351b2b5cn2MEua

#####################################################################################

Legolcsóbb:

TTL to RS485 module Hardware automatic flow control board RS485 mutual TTL signal MCU serial port
https://www.alibaba.com/product-detail/TTL-to-RS485-module-Hardware-automatic_60743269802.html?spm=a2700.7724838.2017115.215.351b2b5cn2MEua

#####################################################################################

Sakk-matt,
KaTT :)

En magamnal power over etherneten hajtok mindent.

A can buszt es a tobbi egzotikumot ott vetettem el amikor a kep atvitele mint igeny felmerult (kamera). Szoval a legelejen:)

Igazan nagy halozatrol nem tudok nyilatkozni, nekem mindosszesen vagy 50 eszkozom lehet.

Amit fejleszteni akarok, hogy 2 szint kozott optika legyen, es ne utp.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Nem biztos, hogy minden problémát kalapáccsal kell megszerelni :-)

Az tiszta sor, hogy kamerának nem valók ezek a mindenféle buszok, de ez fordítva is igaz: ágyúval verébre villanyt ethernet alapon kapcsolni. Még akkor is, ha a sok böszme nagy gyártó erre is wifit használ és a sok nép meg is kajálja. Az 5G is kezd sok lenni, nagyon sok helyen elgurult a gyógyszer. Normális rendszerek kellenének átgondolt integrációval, nem adattal elárasztani a földet (bár ez már megtörtént a bugyuta szelfi őrülettel).

Az én olvasatomban az intelligens otthon/automatizálás nem arról szól, hogy telefonról lehessen kékről sárgára állítani a lámpa fényét. Az igaz, hogy racionális dolgokat nehezebb marketingelni, mert tipikusan nem eléggé sikk.

pedig a kabelezes baromi egyszeru:utp mindenhova

Nem hinnem hogy kalapacs effektus miatt van igy. Rengeteget gondolkodtam rajta, sztem igy a legesszerubb.

A vilagitas az oldscool. Nincs elektronika. Alternativ kapcsolok tomkelege.
Van aramtalanito fokapcsolo, az is oldscool. A lenyegtelen dolgoktol elveszi az aramot.

Az automatizalas a dugaljak es a vilagitason kivuli dolgok:
zsalugater (olyan mint a redony csak vizszintes), nyitaserzekelo, mozgaserzekelo, kamera, kamera reflektorral (ezt vilagitaskapcsoloval vezerlem), kazanvezerles, szivattyuvezerles, szunetmentes, homero, teljesitmenymeres (adott kor szokasos aramot veszi-e fel) stb.

Lenne hova fejlodni... Pl a teljesitmenymeresre egy kis ML-t ra lehetne ereszteni, igy ontanulo lehetne...

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Szia, te nem tartanád túlzásnak, hogy helyiségenként UTP-n vinném a szenzor adatot a központba?

Hogy oldanád meg UTP-n? Mindenhova RPI-t raknál, és RPI-re a szenzorokat? Vagy máshogyan oldanád meg az I2C és SPI-t támogató szenzor bekötését?

I2C extender, UTP-n:
https://sandboxelectronics.com/?product=pca9600-differential-i2c-long-cable-extender-with-buck-convertor-and-rj45-adaptor

SparkFun Differential I2C Breakout - PCA9615 (Qwiic)
11 USD
https://www.sparkfun.com/products/14589

Működési példa:
https://www.youtube.com/watch?v=Km-XAFcmP6c

Itt a leírás, hogy kell elkészíteni:
https://learn.sparkfun.com/tutorials/qwiic-differential-i2c-bus-extender-pca9615-hookup-guide

További példa, I2C-re:
https://learn.sparkfun.com/tutorials/qwiic-hat-for-raspberry-pi-hookup-guide

Másik megoldás, SPI - Ethernet:

http://sch-remote.com/Ethernet-to-RS232TTL-I2C-SPI-Analog-GPIO-PID-SR01E12.php

Ethernet - SPI:

https://www.dx.com/p/w5100-tcp-ip-spi-interface-ethernet-network-module-blue-2056308

https://cablematic.com/en/products/spi-to-ethernet-module-t24-model-usr-es1-UK007/

Ez is nagyon jónak tűnik:

https://www.amazon.com/USR-ES1-ENC28J60-Ethernet-Converter-Module/dp/B07QNRYDBQ/

Vagy:

https://www.amazon.com/SunFounder-ENC28J60-Ethernet-Network-Arduino/dp/B01MEEIC7Z/ref=sr_1_6

Vagy:
https://www.ebay.com/itm/Module-Ethernet-3-3VDC-Interface-SPI-RJ45-pin-header-x2-1-pcs/163377332953?epid=577159393&hash=item260a0c42d9:g:1rcAAOSwa3lb7sI8

Vagy
SPI+I2C:

https://www.ebay.com/itm/MissBirdler-SPI-I2C-Ethernet-LAN-Netzwerk-Modul-ENC28J60-fur-Arduino-Raspberry/312559205848?hash=item48c5fafdd8:g:Yv0AAOSwYvNcpYIh

**************************************

Jól értem, hogy ebben az esetben veszek helyiségenként
1-1 ilyen Ethernet (RJ45) - SPI vagy I2C vagy SPI/I2C modult, a modulra rárakom az 1-3 szenzorom, a kábel másik végét bekötöm egy switch-be, amin az RPI is van, és IP címenként lekérdezem a helységekben lévő szenzorokat RPI-ről? Vagy máshogyan fog működni / máshogyan kell lekérdezni? Így nem lesz szenzor I2C ID ütközés, jól sejtem?

POE-s switch szükséges, ha lesz 3 szenzor rajta, vagy jól sejtem, hogy nem kell POE-s switch?

Sakk-matt,
KaTT :)

Csak a legvégére, mert a tl;dr linkjeidet nincs időm végigmolyolni :(

Ha POE switched van, akkor egy helyen kell konnektor meg tápegység, a drótok végén levő kütyük a dróton kapják a villanyt, nem vagy konnektorhoz kötve, oda teszed, ahova akarod.

Igen, köszönöm az infót a POE-ről, egy ideje építettem ki / használok POE-s eszközöket. Tipikus POE-s eszköz egy POE-s WiFi AP vagy IP kamera, ahol kábelen kapja a villanyt, és bárhova el lehet vezetni úgy, hogy nincs konnektor a környéken (nem kell külön külső tápegység). Limitálva van, hogy portonként mennyi áramot tud küldeni / felvenni az eszköz, 8 port esetén szokott lenni 120-15 wattos fogyasztás a POE-s switch-ben. A Raspberry Pi is támogatja a POE-s táplálást.

Mondjuk ha raknék az RPI-re egy jobb HAT-os erősítőt, azzal már csak POE-n nem megoldható, mert az erősítőnek kell 24V, 120-150 wattos tápegység külön.
(Ez alapvetően sehol nem volt kérdés, csak azért írtam le, hogy javítsam a hülye kérdés / értelmes hozzászólás arányomat, ebben a témában... :) )

Sakk-matt,
KaTT :)

> Szia, te nem tartanád túlzásnak, hogy helyiségenként UTP-n vinném a szenzor adatot a központba?

Szerintem az utp kabel egy olcso kabel, ha korbenezek.
Sot van ugy hogy ingyen is hozza tudsz jutni, pl. bontasnal

>
Hogy oldanád meg UTP-n? Mindenhova RPI-t raknál, és RPI-re a szenzorokat?

Nem.

Kazannak pl ilyen a vezerloje:

https://www.industrialshields.com/shop/product/is-mduino-19r-m-duino-plc-arduino-ethernet-19r-i-os-relay-analog-digital-plus-8?category=1

De lehet ilyet is:
https://wesp32.com/

Vagy csak magat az utp ereit hasznalod, ha nem akarsz a kabel vegere mast.

> POE-s switch szükséges, ha lesz 3 szenzor rajta, vagy jól sejtem, hogy nem kell POE-s switch?

en a raspberryknel poe adom az aramot.
De ha csak a szenzort (nalam a reed rele ilyen) kell akkor eleg a kabelt felhasznalni.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Szia, nagyon jónak tűnő hardvereket linkeltél.

"Vagy csak magat az utp ereit hasznalod, ha nem akarsz a kabel vegere mast."

Azt az 1 kábelt csak erre fogom használni, bárhogy lehet.

A wESP32 jónak tűnik.

Ha jól látom itt a képen:
https://wesp32.com/images/wesp32-pinout.png

https://wesp32.com/files/wESP32-Product-Brief.pdf

Tehát UTP-n, RJ45-ön Etherneten helyiségenként lesz egy ilyen wESP32 eszköz, majd a képen látható sok GPIO-jára bekötöm a szenzorokat, van 2 I2C, 2 SPI busz is.
Így az egymás mellett lévő helyiségeket akár egy ilyenről is be tudom kötni, és csak pár métert kell vinni a szenzorokhoz a kábelt. Jól értem, hogy így működne?

Raspberry PI-vel hogy RJ45-ön, a közös switch-en át kommunikál majd ez, RPI úgy kérdezi le a szenzorokat, és kész?

Tehát újra leírva, így lenne a megoldás:

(1) RPI - (Ethernet RJ45/UTP kábel) - switch-be kötve

(1) I2C és SPI szenzorok (kábellel bekötve a wESP32-be) - wESP32 - (Ethernet RJ45/UTP kábel) - switch-be kötve
(2) I2C és SPI szenzorok (kábellel bekötve a wESP32-be) - wESP32 - (Ethernet RJ45/UTP kábel) - switch-be kötve
(3) I2C és SPI szenzorok (kábellel bekötve a wESP32-be) - wESP32 - (Ethernet RJ45/UTP kábel) - switch-be kötve
(N) I2C és SPI szenzorok (kábellel bekötve a wESP32-be) - wESP32 - (Ethernet RJ45/UTP kábel) - switch-be kötve

Az RPI az N darab wESP32-t kérdezné le TCP/IP-n, a kiépített kábelen, így nézne ki, a switch miatt gyakorlatilag csillagpontosan bekötve.

Sakk-matt,
KaTT :)

Nalam a raspberry pi-ok (tobb van) network booton kapjak sorozatszam alapjan az oprendszert.

A switchbol is van olyan, amelyik poe-t tovabbadja.

Logikailag barmelyik lehet a fonok, akar egy esp is. Fizikailag meg az egyik ablak melletti akar.

Ha ez megvan, akkor lejjebb haladva a fa strukturaban csinalhatsz CAN buszt, ha ep az tetszik, vagy 4-20mA-s szenzort is feltehetsz. A kazanban tervezek meg ilyet bevezetni.

Nekem az osszes ilyen busszal az a bajom, hogy kepatvitelnel megall a tudomany. Es kb. mindig felmerul az igeny.

En most az esp cameraval akarok futni egy kort.

De kezdheted ugy is, hogy van 2 raspberry-d (egy fonok, meg egy kliens, ami az erzekeloket adja). Majd lesz 3 raspberry-d. Majd az egyiket lecsereled esp32-re. Majd hozzaadsz egy I2C erzekelot. Majd az erzekelot elviszed 6 meterre egy I2C->ethernet atalakitoval, stb, stb.
Erted, fel tudod epiteni a rendszert apro lepesekkel.

A CAN busszal az elso evben kb. nem is lesz sikerelmenyed. Ahhoz elobb utobb kell egy CAN busz sniffer, egy replayer. Kellenek mini test-setupok, stb, stb.
De ha CAN busz, itt egy tok jo beszamolo:
https://medium.com/@tbruno25/car-hacking-how-i-added-features-by-manipulating-can-bus-and-how-you-can-too-b391fcea11f1

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Szia, nekem is network boot lesz az RPI-vel, NFS-en fog menni, NAS-ról.
Úgy terveztem, hogy egy RPI dolgozza fel az összes szenzor adatot.
Nem akarok CAN buszt, ha RJ45 alapon is meg tudom oldani, 10 USD-s eszközökkel.
Belátom, hogy a CAN buszos megoldáshoz egészen sok időt kellene rátolnom, hogy tökéletesen menjen.
RJ45 irány most egyszerűbbnek tűnik, még akkor is, ha overkill bizonyos szempontból, de amúgy is UTP kábelek vannak kihúzva.

Ahogy írtam, az a fő kérdésem, hogy megoldható-e úgy, hogy

1. RPI RJ45 UTP Etherneten switch-be van kötve, ez dolgozza fel az összes szenzor adatát, amikkel a switch-en át van kapcsolatban.

2. Az ESP vagy bármilyen modul RJ45 Etherneten switch-be van kötve, ahova az RPI, és ebben az ESP-be vannak kötve az 1-3 szenzor, nem kamerák. Az ESP-en át az RPI le tudja kérdezni a szenzor adatait, vagy az ESP alapból lekérdezi, és csak az RPI valahogy lekérdezi, esetleg az RPI nem kérdezi le, hanem az ESP vagy bármi feltölti X időnként a szenzor adatokat az RPI-re, NAS-ra NFS-en, de inkább egy TCP/IP-n futó alkalmazásra, bárhogyan. A lényeg hogy eljusson az adat.

3. Mint a 2.

4. Mint a 2.

5. Mint a 2.

6. Mint a 2.

Tehát lenne 1 központi RPI és lenne például 5 ESP vagy bármi, amin lennének a szenzorok, RJ45 / Etherneten kötve, switch-en át.

Amiket linkeltem eszközök, azokkal meg lehet ezt oldani? Melyiket javasolnád, és miért?

Sakk-matt,
KaTT :)

Mi a konkret hardver ami mar megvan (a kezedben van), mi az amit mar megrendeltel, de meg uton?

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

3x RPI 3B+ (azért 3, mert lesz multiroom audio + erősítő RPI alapon, de az külön projekt, alapvetően 1 RPI-t szánok erre)
1x NAS (NFS, TFTP, RAID 1-ben disk-ek) + külső mentés
Gigabit és 100 megás switch-ek és egyéb hálózati eszközök (az RPI-s eszközök külön fizikai hálózaton lesznek a szenzorokkal, első körben nem lehet sehogy sem elérni, csak a gépemben lévő 2. hálózati kártyáról)
I2C/SPI-s szenzorok (2x hő, 2x fény érzékelők)
Phat Stack GPIO extender

Továbbá:

https://shop.pimoroni.com/products/breakout-garden-hat-i2c-spi

https://shop.pimoroni.com/products/breakout-garden-phat

https://shop.pimoroni.com/products/bme680-breakout

És még 2 breakout-os fény szenzor

https://www.amazon.co.uk/gp/product/B07912JHDK/ref=ppx_yo_dt_b_asin_title_o02_s01?ie=UTF8&psc=1

Forrasztani az ősrégi legyen páka helyett: (másra is kellett)

https://www.soselectronic.hu/articles/weller/we-1010-oktato-keszlet-forrasztoallomas-extrakkal-2229
+ forrasztócsúcsok még:
https://www.amazon.co.uk/gp/product/B078MFRWX6/ref=ppx_yo_dt_b_asin_title_o02_s02?ie=UTF8&psc=1
és Tabiger Solder Wire with Rosin Core 97Sn-2Rosin 0.7Cu-0.3 Ag, Pack of 2 Solder Wire 1 mm and Solder Wire 0.8 mm
https://www.amazon.co.uk/gp/product/B07LCGMJWL/ref=ppx_yo_dt_b_asin_title_o02_s02?ie=UTF8&psc=1

Van még sok kábelem és egyéb kiegészítő: multiméter, kábel tesztelők, stb.

Nincs úton semmilyen modul, ami ide kellene, mert még nem egyértelmű számomra, hogy melyik a legjobb, és nem akarok feleslegesen venni semmit (a fentieken kívül :) ).

Sakk-matt,
KaTT :)

Tehát vettél olyan pimoroni dugványokat, amiket az rpi-re KELL dugni. Csak te nem akarod rádugni.

De, a pimoroni csatlakozós szenzorok lesznek a közelben, vagy a fő RPI gépen, az egy helyiségnek oké. Azonban a többi helyiségben RPI nélkül akarom megoldani, amik távolabb vannak.

Sakk-matt,
KaTT :)

just do it. de komolyan. Nem ertem mit ragodsz...

Van egy raspberryd, van i2c szenzorod a kezedben es meg nem hasznalod?!

Dugd ossze rakd ahova gondolod ha bugzik, akkor tegyel 2 ilyet:
https://www.sparkfun.com/products/14589

Haladjal, ahelyett, hogy itt a vegtelensegig tervezgeted.

Ha nem fer fizikailag el a raspberry akkor rakj esp-t, ha gany a tap, vagy egyszeruen nem fer el, akkor poe.

Nincs itt kulonesebben min ragodni

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

"Van egy raspberryd, van i2c szenzorod a kezedben es meg nem hasznalod?!"

Ki mondta, hogy nem használom? :)
Csak nem tudom elvinni egy távolabbi helyiségbe jelenleg, lásd ez a téma :)

"Dugd ossze rakd ahova gondolod ha bugzik, akkor tegyel 2 ilyet"

Igen, ilyesmit keresek.

Sakk-matt,
KaTT :)

Ha mindenhova UTP, akkor az baromira sok kábel. Egy buszkábelnek előnye, hogy elég sok kütyüt rá lehet fűzni: ha csak 20 kütyüd van azon az egy buszkábelen, akkor már ott vagy, hogy 20 helyett 1 kábel. Húsz kábel elég nagy köteg, nem egyszerű elvezetnit. És akkor azt a 20 kábelt meg is kell szerelni, be is kell dugni valahova (ha ethernet, akkor switch kell, ha nem ethernet, akkor is be kell dugni valahova, amit meg kell venni, hely kell neki, ráadásul jó eséllyel aktív eszköz, tehát áramot is fogyaszt).

feltunoen keves dolgot tudtam felfuzni: ablaknyitaserzekelo es mozgaserzekelo egy kotodobozba osszejon. Kb. ennyi.

Azt lehetne, hogy kotodobozonkent agazok szet es nem egy fodobozbol olelek fel 3 helyiseget. De csak magamat szivatnam, egy kotodoboz nem tul nagy hogy aktiv eszkozt szuszakoljak bele.

Szoval lehetne felfuzni, de nagyon nincs mit nalam.

Viszont a mostani elrendezesben benne van az is, ha kedvem lenne jatszani akkor itt-ott lecserelem valami buszra az ethernetet. "downgradelni" egy-egy szakaszt barmikor lehet.

Ez ilyen fa struktura nalam.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

"Ha mindenhova UTP, akkor az baromira sok kábel. "

Nem gond, nekem ez adott, már ki van építve. Igen, sok sok kábel.

"És akkor azt a 20 kábelt meg is kell szerelni, be is kell dugni valahova (ha ethernet, akkor switch kell, ha nem ethernet, akkor is be kell dugni valahova, amit meg kell venni, hely kell neki, ráadásul jó eséllyel aktív eszköz, tehát áramot is fogyaszt)."

A fentebb megoldás szerint wESP32-vel a sok adatbusza miatt lehetséges, hogy elég lesz 2-5 wESP32-t UTP-n (azaz nálam konkrétan S/FTP-n) a helyiségekbe vezetni, és az egymás melletti helységeket le tudom fedni egy ilyennel, akár 4-5 helyiséget is, ha pont középre rakom be a wESP-et és pár méterre lesznek a szenzorok. Tehát nem 20 kábelt fogok felhasználni, hanem 2-5 darabot, ha ezzel az eszközzel így megoldható. 2-5 UTP kábel kb 20-30 szenzor bekötésére szerintem még nem vészes, ráadásul csillagpontosan, tehát ha bármi van az egyik helyen, csak az a blokk esik ki, míg adatbusznál lehet, hogy több minden eshet ki. De mindegy is, mert nekem csillagpontosan adottak az UTP kábelek, és bármennyire is jó az adatbusz, a csillagpontos irányt fogom választani ezért.

Sakk-matt,
KaTT :)

Ahogy ránéztem az adatlapra, egy ilyen wESP32 13W-ot eszik, ami elég sok.
Tény, hogy így spórolsz egy csomó kábelt.
Egyébként a busz kábelnél nem gond, ha kiesik egy közbenső elem, legalábbis az általam használtnál nem gond.

Néhány éve az automatizálással az volt a gond, hogy villamosmérnökök akarták megoldani (szoftveres platform szegényes), most pedig az a gond, hogy informatikusok akarják megoldani (minden ethernet alapon, aztán jön az 5G). A megoldás valahol a kettő között lenne.

Szia, igen, nekem is soknak tűnik a 13W, de az irány jó.
Van benne WiFi, nincs rá szükségem, sem a BT-re. Ki lenne kapcsolva, és feleslegesen benne van. Fentebb linkeltem csomó RJ45-I2C/SPI átalakítót, azokról mit gondolsz?

Például ezekről:

https://www.ebay.com/itm/MissBirdler-SPI-I2C-Ethernet-LAN-Netzwerk-Modul-ENC28J60-fur-Arduino-Raspberry/312559205848?hash=item48c5fafdd8:g:Yv0AAOSwYvNcpYIh

https://www.amazon.com/USR-ES1-ENC28J60-Ethernet-Converter-Module/dp/B07QNRYDBQ/

https://www.amazon.com/SunFounder-ENC28J60-Ethernet-Network-Arduino/dp/B01MEEIC7Z/ref=sr_1_6

https://www.sunfounder.com/enc28j60-ethernet-lan-network-module.html

https://www.ebay.com/itm/Module-Ethernet-3-3VDC-Interface-SPI-RJ45-pin-header-x2-1-pcs/163377332953?epid=577159393&hash=item260a0c42d9:g:1rcAAOSwa3lb7sI8

Ez a fenti 4 közül szerinted melyik a legalkalmasabb a célra és miért?

"Néhány éve az automatizálással az volt a gond, hogy villamosmérnökök akarták megoldani (szoftveres platform szegényes), most pedig az a gond, hogy informatikusok akarják megoldani (minden ethernet alapon, aztán jön az 5G). A megoldás valahol a kettő között lenne."

Mint látod, én próbálom nem Ethernet alapon megoldani, de csak arra terelődöm.
5G biztos nem, maga az elv sem tetszik így elsőre. Az 5G egy ideális világban, csak jóindulattal, hacker-ek nélkül jó lenne.
Én kábel alapú megoldást keresek, elvből.

Sakk-matt,
KaTT :)

> Fentebb linkeltem csomó RJ45-I2C/SPI átalakítót, azokról mit gondolsz?

En ezekrol az atalakitokrol az a velemyenem, hogy pl. adott egy homero ami adott esetben 10centire lenne a uC-re, most valami miatt a haz kulso falara kellene kitenni (vezetekesen), akkor atalakitoval "megtoldom" a 10 centit.

En ugy csinaltam, hogy elkezdtem raspberryket kitenni, majd lecserelgettem oket, ahova nem kellett kepfeldolgozas (kamera). Ez igy egy gradualis fejlodes. Elkezdheted kicsiben. Egy reflektoros kamerat felraksz. Majd folytatod ezzel-azzal. Es tudod cserelni, "downgradelni" egy-egy vonalat.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Nekem NEM lesz kamera sehol. Hőmérők, fény szenzorok lesznek, amiket 1-3 percenként kérdezek le kb. Tehát ezért érzem az RPI-t soknak, mert nincs mit feldolgozni, csak a központi RPI-hez kellene UTP kábelen eljuttatni a mért értékeket. Ennyi.
Amiket linkeltem, azok az RJ45-I2C/SPI-s cuccok jók erre?

Nem akarok downgrade-elni azt, amiről már induláskor tudom, hogy overkill. Inkább egyből a jobb megoldást akarom.

Sakk-matt,
KaTT :)

> Nem akarok downgrade-elni azt, amiről már induláskor tudom, hogy overkill. Inkább egyből a jobb megoldást akarom.

Jo, csak eloszor a szoftveroldalt ossze tudod rakni, es miutan mukodik a hardvert kezded tutujgatni.

De kezdheted esp-vel rogton. _Franko_ is azt csinalgatja. Szerintem mehetnek az ilyen i2c transceiverek, de meg nem probaltam oket. Azt hittem a topologianal vagy meg elakadva.
Egyaltalan a CAN busznak milyen kabelt huznal be? (ha can busz maradna)

Egyebkent rs485 utp-n is at tud menni:
https://electronics.stackexchange.com/questions/33455/is-cat5-cable-good-enough-for-rs-485-vs-true-rs-485-cable

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

"Jo, csak eloszor a szoftveroldalt ossze tudod rakni, es miutan mukodik a hardvert kezded tutujgatni."

Már összeraktam 1 RPI-t, amin vannak szenzorok I2C-n és mentek SPI-n is. Az lenne a következő lépés, hogy Etherneten RJ45-ön távolról lekérdezni a szenzort, közötte UTP kábel. Ehhez keresek hardvert, amire jó esetben csak I2C vagy SPI buszon bekötöm a szenzort, az eszközt RJ45-ön kábelre dugom, a kábelt a switch-be, amiben az RPI van és kész.

CAN helyett:

Mivel egyszerűbbnek tűnik, Ethernet / RJ45 / TCP/IP és várhatóan TCP szinten kommunikálnék az RPI és az ESP / modul között, UTP jellegű kábelen.

Sakk-matt,
KaTT :)

Ha jól értem az a terved, hogy ezekbe a "konverterekbe" bedugod az ethernetet az egyik oldalra, a másikra meg közvetlenül egy SPI vagy I2C hőmérőt, barométert, wathever.

Az a probléma ezzel a koncepcióval, hogy a linkelt eszközök erre teljesen alkalmatlanok. Ezek kommunikációs modulok, arra találták őket ki, hogy az SPI/I2C oldalra egy mikrokontroller kerüljön (pl ESP vagy Arduino vagy STM vagy akármi) és a megfelelően implementált kóddal tudj etherneten csomagokat küldözgetni a mikrokontrollerből. Ha csak simán összehuzalozod a szenzorral a modult, nem fog csinálni semmit.

Ugyanez igaz a korábban linkelt CAN-SPI eszközökre, korábban Igiboy írta is, de ez a részlet elsikkadt:
https://hup.hu/node/164703#comment-2359339

"Az a probléma ezzel a koncepcióval, hogy a linkelt eszközök erre teljesen alkalmatlanok. Ezek kommunikációs modulok, arra találták őket ki, hogy az SPI/I2C oldalra egy mikrokontroller kerüljön (pl ESP vagy Arduino vagy STM vagy akármi) és a megfelelően implementált kóddal tudj etherneten csomagokat küldözgetni a mikrokontrollerből. Ha csak simán összehuzalozod a szenzorral a modult, nem fog csinálni semmit."

Tehát ezért tereltek arra, hogy SBC legyen az, ami feldolgozza a szenzorok adatait, mert nincs olyan kisebb eszköz, ami Etherneten át tudná simán küldeni azt az 1-3 szenzor adatát, amit I2C-n vagy SPI-n érek el?

RPI alapon akkor a legegyszerűbb lekérdezni a szenzort, és nincs más butított cucc, amiről lekérdezhető lenne?

Ha nagyon sok időm lenne és megfelelő hátterem, most betömném a nagy piaci rést, és csinálnék egy RJ45-ön és másik változatként WiFin működő kis mini eszközt, ami csak annyit tud, hogy lehet rá kötni I2C és SPI buszos szenzorokat, és az eszközről lekérdezhető, vagy éppen az eszköz TCP-n feltölti ahova kell az értékeket valamin keresztül. (Lennie kell ilyennek, csak biztos még nem találtam meg. Annyira triviális és nyilvánvaló igény ez, az én nézőpontomból.)

Ha jobban értenék hozzá, akkor most tudnám, hogy miért nincs még ilyen termék tömegesen a piacon.
Ezzel a termékkel megvalósulna az okos otthont építő cégek/vállalkozók rémálma, hogy egyszerű lenne okos otthont csinálni kábelen is: RPI + Home Assistant, UTP kábel (vagy Wifi, bár Wifin már sok ilyen van) a switch-be, switch-be UTP-vel ez a RJ45-I2C/SPI modul, a modulra a szenzorok, config beállítás és KÉSZ.

Tehát ez:

https://solarbotics.com/product/31050/

"We're carrying the WIZnet WIZ811MJ module to support the Adafruit Ethernet Shield Kit. It's an assembled and tested breakout board for the W5100 ethernet chip that has a built-in TCP/IP stack. What's that mean? It talks networking, so you don't have to know how (or know that much to make it work).

Please note that these modules are unlike XPort XBee modules, these communicate over SPI (not serial), and don't have a built-in DHCP client.

Features
Plug-in module
Usable without H/W design for W5100, Transformer and RJ-45
Available of fast evaluation of W5100 and MCU in the target board
Supports MCU BUS and SPI Interface
Supports Auto MDI/MDIX (auto detection of crossover)
Supports network status indicator LEDs - FDX, TX, RX, Link, Collision
Specifications
Architecture
TCP/IP - W5100
PHY - Embedded in W5100
Mag Jack - PPT RJ113BZ
Interface - 10/100 base-t ethernet (auto detection)
Network Protocol: TCP, UDP, IP, ARP, ICMP, IGMP, PPOE, Mac
Dimensions: 55.5 x 25.0 x 23.5mm
Connector Type: 2.54mm pitch 10x2 header
PCB Through Hole: Two PCB Through Holes (3.00mm)
SPI Signal Pin: Separate SPI Signal Pin (spi_en controlled automatically by /scs signal)
Input Voltage: 3.3v internal operation, 5v tolerant i/os
Power Consumption: 10, 100 base t max 185ma (3.3V)
Temperature: 0 ~ 70c"

Itt egy csomó ESP32-es alternatíva:

https://www.olimex.com/Products/IoT/ESP32/

Konkrétan:

https://www.olimex.com/Products/IoT/ESP32/ESP32-POE/open-source-hardware

https://www.olimex.com/Products/IoT/ESP32/ESP32-POE-ISO/open-source-hardware

Tehát egy ilyen ESP32-es eszközön mit kell állítani, hogy le tudjak kérdezni 3 darab I2C-s szenzort, más-más I2C ID-n?
Hogy állítom be a szenzorokat, hogy kérdezem le TCP/IP-n?

A válasz, BME680 szenzor esetén:

http://www.esp32learning.com/code/esp32-and-bme680-sensor-example.php

https://github.com/gschorcht/bme680-esp-idf

7 lépésben: ESP32 WiFi Weather Station With a BME280 Sensor
https://www.instructables.com/id/ESP32-WiFi-Weather-Station-With-a-BME280-Sensor/

Connect the ESP8266 WiFi Chip to your Raspberry Pi
https://openhomeautomation.net/connect-esp8266-raspberry-pi

Szóval itt azért a szoftver része is jelentős, az ESP32 esetében biztosan.

Sakk-matt,
KaTT :)

Az ESP egy jó irány mondhatni modern, gyors, népszerű.

Emellett amit érdemes kipróbálni, az valamilyen Arduino + POE shield.

Mind a kettő mikrokontroller nem beállítod, hanem a saját nyelvén, a saját eszközeivel programozod. Az Arduino környezet kezdőknek egyszerűbben programozható, az ESP viszont tud OTA, firmware frissítést ami esetedben jó lehet.

Bizonyos ESP modellek szintén Arduino kompatibilisek, én ilyet néznék a helyedben.

Köszönöm, de első körben a Raspberry Pi irányt választom, és a későbbiekben, ha eljutok oda, akkor fogom még egyszerűbben kivitelezni ezt. Próbálom minél gyorsabban összerakni a hardver részét, és az én esetemben ez RPI alapon a leggyorsabb, még ha én is látom, hogy overkill pár szenzort rádugni és ezért üzemeltetni.

Sakk-matt,
KaTT :)

> Ahogy ránéztem az adatlapra, egy ilyen wESP32 13W-ot eszik, ami elég sok.

Max. 13W-ot tud kiszolgalni, igen. Motorbol nagyobbat mar nem tud meghajtani.
Jo lenne egy 25W-os valtozat is.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

A wESP32-ben gondolom kikapcsolható a BT és WiFi is. Van esetleg olyan változata, amin nincs feleslegesen BT és WiFi, csak RJ45?

Sakk-matt,
KaTT :)

Hat ez espwroom32-vel jon. Leforraszthatod rola.
https://www.espressif.com/sites/default/files/documentation/esp32-wroom-32_datasheet_en.pdf

Nekem a legnagyobb szivfajdalmam, hogy pont nem fer be egy 80-as kotodobozba, mivel amerikai a foszer, ott meg a szogletes gipszkarton doboz divik. Tul keson szoltam neki, meg igazabol nem sikerult meggyoznom.

De itt a kapcsolasi rajz, elotted a palya:
https://cdn.hackaday.io/files/853893653282976/wESP32-1.pdf

:)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Hát, inkább keresek másik terméket, minthogy forrasszak, de ha nincs más, forrasztok. :)
Csak pazarlásnak érzem, hogy veszek egy légkondis, CD lejátszós autót, majd kikötöm a CD-t és a légkondit :) Főleg, hogy már az elején tudom, hogy ezek nem kellenek. Köszönöm az infókat, nagyon részletes és komoly cucc! :)

Sakk-matt,
KaTT :)

+1

Mint fentebb írtam, Etherneten, UTP-vel meg tudnám oldani, de ez ahogy írtad is, ágyúval verébre lenne, hogy egy gigabites/10 gigabitet is elbíró UTP kábelen, TCP/IP-n, TCP csomagokban gyakorlatilag pár számot küldök át 1-5 percenként.

Ha kamerákat is akartam volna, megcsinálom UTP kábel alapon és hozzácsapom a szenzor adatokat is. Nekem azonban nincs szükségem (web)kamerára, csak x percenként szenzor adatokat kiolvasni, kábelen át. Azért kábel, mert nem akarom WiFin küldeni ezeket, elvből. Egyszerűbb lenne a millió kész kütyüvel, ami már mindent tud. Olyan is lenne, ami hekkelt firmware-rel már nem beszélne haza Kínába, csak néha-néha :)

Ez olyan terület, amivel most foglalkozom először mélyebben, mint ahogy a hozzáértőknek ez nyilvánvaló volt.

Nem baj, innen-onnan felszívom a megfelelő tudást, és majd tudok segíteni az ittenieknek, ha elakadnak ebben is... :-)

Gondolom rájöttetek, hogy én ezt elvi okokból csinálom, mint kitűzött cél és fejlődési lehetőség. Más szóval: hobbi. Tehát hiába nem segítetek, hiába tudjátok a megoldást és nem mondjátok meg, idő kérdése, és meg fogom oldani. (Lehet sok idő, de ráérek.) Ha segítetek 1-1 részben, ha nem, akkor sem veszem el a megélhetéseteket, mert én elvből nem akarom ezt megvenni mástól készen, hanem én akarom elkészíteni.

Olyan ez, mint a fotózás: vannak profi fotósok, de én a saját gépemmel, tudásommal, lehetőségeimmel akarom elkészíteni a képet, és előhívni, hiába más jobb képet csinálna, nekem a sajátom kell. Ha nem lesz jó a kép, próbálom újra, jobb időben, jobb felszereléssel, jobb beállításokkal, jobb szaktudással.

Sakk-matt,
KaTT :)

SUB
--
"Csak webfejlesztést ne..." -ismeretlen eredetű szállóige-

Biztos hogy mikrokontrollerrel (ESP32 vagy ilyesmi akármilyen arduino) építenék BLE mesh vagy wifi networköt.
MQTT-n betolnám az adatokat RPI-be és már kész is vagy, ezer a lehetőség.
Az egyszerűbb a sima wifi de ez többet fogyaszt. Ha fontos a fogyasztás (nálam nem) akkor játszani kell a BLE-vel meg egyéb mesh cuccokkal.
RPI-hez szerintem BLE gateway se kell.
Komplett infrastruktúra tök jó leírásokkal van a neten az ESP-khez, firmware frissítés meg minden megoldható központosítva.

--
Gábriel Ákos

Szia, köszönöm az infókat.

Tehát te helyiségenként raknál egy ESP-et / Arduinót (esetleg RPI-t)?
Nem ismersz olyan hardvert, ami még egyszerűbb, mint az ESP, és egyszerűen RJ45/UTP-n továbbítaná az 1-3 szenzor adatait, amit az RPI tudna olvasni/lekérdezni?

Most ott tartok, hogy RPI-vel helyiségenként meg tudnám csinálni, csak pazarlásnak tartom, hogy 1-1 RPI legyen ott ezért.
Aztán optimalizálva lehetne, hogy a környező helyiségekben lenne csak 1 RPI, így lehet, hogy megúszom jóval kevesebbel, azonban még ez is soknak tűnik, hogy csak az 1-3 percenkénti 3-9 szenzor leolvasás miatt legyen ott egy komplett operációs rendszer minden funkciójával.
Azt gondoltam, hogy lennie kell valami egyszerűbbnek, ami csak a 3 szenzort elérhetővé tenné RJ45/UTP-n elérhetővé, lekérdezhetővé, vagy lekérdezné csak ezeket, és bárhogy feltölteni az RPI-re, ahogy írtad akár MQTT kliensként az RPI szerverre.

Nekem adott a kiépített UTP kábelezés csillagpontosan az RPI központba. Tehát sem a BLE sem a WiFi nem út.
Tehát ha keresek olyan ESP-et, amin van RJ45, akkor kb meg kell írni a szenzor lekérdezést ESP32-re, majd MQTT-n mint kliens az RPI-nek küldöm, aki az MQTT bróker / szerver?

Ilyeneket találtam:

https://iotdesignpro.com/projects/how-to-connect-raspberry-pi-with-mqtt
https://techtutorialsx.com/2017/04/24/esp32-connecting-to-a-wifi-network/

Vagy csinálhatom ugyanezt RPI alapon (ahogy javasolták nem rég: Orange Pi Zero-val), hogy lekérdezem a szenzort, és átküldöm az RPI-nek valahogy.

Ha UTP kábelen működne valamilyen ESP32 POE-n, mennyivel fogyaszt kevesebbet, mint egy Orange Pi Zero, ami POE-n megy?

Sakk-matt,
KaTT :)

Kicsi kontroller: Arduino Uno, Nano. Mindegyikhez van ethernet shield, elküldheti az adatokat a pi-nek, vagy hagyja, hogy a pi kérdezze le tőle.

Kis barkáccsal POE is lehet.

Értem, köszönöm.

Akkor ha jól sejtem, a komolyabb hardver barkácsolás helyett 2 fajta utam maradt: (a jelenleg nem ismert többi úton kívül)

1.A: Orange Pi Zero + POE: egy UTP kábelen jön adat és áram, majd megoldom, hogy menjen NFS-ről

( https://rhasbury.wordpress.com/2019/05/27/orange-pi-zero-spi-eeprom-based-nfs-boot/ ), majd a Raspbian szerveren szépen megoldom, hogy menjen például az I2C busz, és rákötöm a szenzorokat.

Előny:
- könnyen összerakható hardver
- scriptelhető, programozható Linux szinten a gép (nekem ez előny)
- könnyen más funkcionalitás is rárakható
- 100 mbites full duplex kapcsolat (ha akarnám lehetne gigabites is más hardverrel de felesleges)
- I2C ID ütközést könnyű megoldani (másik I2C busz használat, vagy más út)

Hátrány:
- nagyobb fogyasztás egy célhardverhez képest
- sok felesleges hardver modul a zero-ban benne (WiFi, BTE, stb), amit nem lehet nem megvenni nélküle
- nagyobb működési overhead a kész hardverhez képest
- drágább, mint az ESP-s irány

2. Arduino Uno, Nano, wESP32 vagy más ESP alapú eszköz:

Előny:
- kisebb fogyasztás egy RPI-hez képest
- kevesebb felesleges hardver modul, amire nincs szükségem (WiFi, BTE)
- 100 mbites full duplex kapcsolat (ha akarnám lehetne gigabites is más hardverrel de felesleges)
- kisebb működési overhead az RPI-hez képest: csak azt csinálja, amit kell
- relatíve olcsó

Hátrány:
- nehezebb és körülményesebb beüzemelés (nekem az RPI-hez képest, amit már jobban ismerek + Linux miatti könnyebbség)
- nehezebben összerakható hardver
- nem scriptelhető, programozható Linux szinten a gép, csak külön a maga módján
- más funkcionalitás nehezebben rárakható
- Linux szerű script-elés nem megoldható
- I2C ID ütközést nem tudom, hogy milyen könnyű megoldani :)

Álmaim hardver megoldása, amiről nem tudok, hogy létezne:

Előny:
- megy POE-n, RJ45-ön kapja az áramot is
- 100 mbites kapcsolatot elég, ha tud Etherneten
- kisebb fogyasztás egy RPI-hez képest
- nincs felesleges hardver modul, amire nincs szükségem, csak RJ45 van kommunikációhoz
- kisebb működési overhead az RPI-hez képest: csak azt csinálja, amit kell
- relatíve olcsó
- könnyen összerakható hardver
- könnyen beállítható az a maximum 3 I2C/SPI szenzor, amit kezelni kell: valami egyszerű konfig fájl vagy egyszerűen beállítható nyelvben valami és kész
- az RPI-re könnyen beállíthatóan feltölti az adatokat, vagy az RPI könnyen le tudja olvasni, támogatottan
- bónusz lenne, ha kezelné az I2C busz ütközéseket is, tehát azonos I2C ID-jű szenzorokat is tudna kezelni kevés idő ráfordítással, konfigurálással

Hátrány:
- ha RPI árban vagy olcsóbb lenne, az még beleférne

Sakk-matt,
KaTT :)

http://wiki.seeedstudio.com/Arduino_Software_I2C_user_guide/
(Nem használtam, nem ismerem, csak neked kerestem.)
És hasonló kell SPI-re is, mert az ethernetvezérlő SPI-n lóg.

"Másfelé írtad, hogy sw-ben otthon vagy nagyon de hw-ben nem."

ESP32-re létezik több "script nyelv" pl.: python, lua, javascript
Python, lua alól (a leírások alapján) használható az ethernet interfész is.
Ezek az interpreterek sok szenzorhoz tartalmaznak kész drivert is.
Ha nem akarod használni a WIFI-t, az le is tiltható, ilyenkor egész baráti lesz a fogyasztás is.
(Azt nem tudom, az ethernet csatoló mekkora fogyaszástöbbletet hoz be.)

Engedjetek meg egy butuska kérdést!

Ha van egy olyan Mduino PLC-m, amire installáltam a Modbus/tcp protokollt ÉS
van a PLC-n SPI interface, akkor ezt a PLC-t lehet használni CANbus/Modbus konverternek (természetesen a konvertáló szoftver megírásával)?

> Sol omnibus lucet.

Arduino van benne, szóval ugyanúgy meg lehet csinálni mint egy arduino lappal és a kiegészítőkkel.
Az SPI részre kötöd a CAN hálózati interfészt.
Hogy mire jó az átalakítás azt nem tudom így kitalálni.

Köszönöm!

Az átalakítás arra jó, hogy az analog és a digitálási bemeneteket és kimeneteket egy PC-ről olvasom/írom Modbus/TCP protokollal így, ha a PLC-re felfűzöm a CAN-buszt, az azon kiolvasott adatokat is modbus registerbe tehetem és PC oldalon nem kell a CANbus-szal foglalkoznom.

Más szavakkal: A PC egységes felületet lát, ez a projectben előny. Alternatív lehetőség egy CAN/Eth konverter, de ez külön pénz, 2 ip_cím, a konvertert külön konfigurálni kell, bonyolódik a PC oldali driver stb.

Még egyszer köszönöm, sejtettem, hogy ez a megoldás, de mezei szoftveresként hardverből gyengus vagyok, így kellett a megerősítés.

> Sol omnibus lucet.

Járható lehet az út.
Bár mostanában azt tapasztalom, hogy mindenki mindenféle protokollt leginkább Ethernet-re konvertál, ez a legrugalmasabban átvihető.
Elég csak a WiFi-re gondolni, vagy VPN-re, de akár az optikai kábeles galvanikusan leválasztott kapcsolat is fillérekből megoldható.
Ami még jó az ethernetbe, hogy minden utcasarkon találni hozzá alkatrészt. Lehet nem lesz ipari amit találsz ilyen gyorsan, de ha épp gyorsan kell javítani akkor az is megteszi és megy addig is a termelés.
Van ethernet is a dobozodon, ha jól láttam.

Persze, a Modbus/tcp már megy is, ezért gondoltam, hogy a CANbus-os szenzorokat SPI-n integrálom és a mérési adatokat beteszem egy-egy modbus regiszterbe.

> Sol omnibus lucet.

De csinálhatsz a modbussal párhuzamosan egy can-ethernet bridge-t is.
Akkor nem kutyulsz bele a modbus-tcp-be

Pont, hogy bele akarok kutyulni. Kliens oldalon csak annyi kell akkor, hogy 2-3-mal több regisztert olvasok be ugyanazzal az utasítással. A CANbus-on kiolvasott értéket egyszerűen beírom az Mduino egyik szabad (van bőven!) modbusregiszterbe.

> Sol omnibus lucet.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
9.4 SPI – MISO/MOSI/SCK
These pins can only work as a 5V pins if the Ethernet protocol is not
going to be used. As the Ethernet protocol uses the SPI to communicate with
the Arduino board, both behaviours cannot happen at the same time as the
Ethernet would not work.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

> Sol omnibus lucet.

Kannás buszMesterek! (Bocs, a téma neve miatt kihagyhatatlan volt.)

Jól látom, hogy az alábbi módszerrel, azaz kész hardverekből összelegózva:

- I2C-s szenzorokat tudok kezelni

- CAN buszt vagy ModBus-t vagy bármilyen más egyéb buszt tudok használni

- A BeagleBone Green-re akár az összes 20-30 szenzort fel tudom fűzni különböző Grove használattal?

- Konkrétan úgy tudok I2C buszos Grove szenzort bekötni, hogy egy hozzá való 4 pines kábellel rákötöm a Green-re, I2C Hubra és megy? Vagy valamilyen adatbusz modulra? Mindenféle forrasztás nélkül?

Ezeket találtam hg2ecz konkrét javaslatára:

- BeagleBone Green ( https://beagleboard.org/green )

Ez lesz a központi egységem, amire befutnak az adatok és vezérli az egészet.

Lesz hozzá egy BeagleBone ModBus CANBus Cape ( https://elinux.org/BeagleBone_ModBus_CANBus_Cape ), ezt rakom a BeagleBone Green-re. Így lesz ModBus / CANBus

Majd erre rákötöm valamilyen módon 2 vagy több érpáron (10-30 méterre akár) a Cape-eket vagy Grove-okat helyiségenként, akár 4-8 darabot, például:

BeagleBone Comms Cape ( https://hu.mouser.com/new/beagleboardorg/beaglebonecapes/ )

Amire rákötöm I2C-n a szenzoraimat (pár méterre a Comms Cape-től), és kész?

Kihagytam valamit? Ez így működhet?

Beagle összehasonlítás:

https://eu.mouser.com/new/seeedstudio/BeagleBone-black-vs-green/

És a Green támogat Grove Sensor-okat, jelenleg 115 félét:

https://eu.mouser.com/Search/Refine?Ntk=P_MarCom&Ntt=146043639

Itt 133 fajta:

https://www.seeedstudio.com/category/Sensor-for-Grove-c-24.html

Tehát veszek még ilyen kábeleket:

https://www.seeedstudio.com/Grove-Universal-4-Pin-Buckled-20cm-Cable-5-PCs-pack.html

És kb összelegózom a hardvert? (Nyilván szoftveresen is meg kell oldani az I2C és szenzorok kezelését, de a hardver része kész.)

Beaglebone Green

Ha több szenzor kell:

Grove - I2C Hub
https://www.seeedstudio.com/Grove-I2C-Hub-p-851.html

És a szenzorok?

Sakk-matt,
KaTT :)

"És a szenzorok?"

Igen.

"(Nyilván szoftveresen is meg kell oldani az I2C és szenzorok kezelését, de a hardver része kész.)"
Kész.
Teljesen.
Lepárhuzamosítottad az összes I2C eszközt. A címek ugye egyediek? Vagy azt megoldod szoftverből, szokás szerint.

8 USD-ért veszek ilyet:

Grove Base Cape for Beaglebone v2.0
https://www.seeedstudio.com/Grove-Base-Cape-for-Beaglebone-v2-0-p-2644.html

Van rajta:

12 Grove Connectors includes
2x UART
2x Analog Input
4x Digital I/O
4x I2C Interface

Minden szenzort amit néztem, az legalább 2 féle ID-t tud felfenni, tehát akkor így van +4 I2C interface, azaz (1+4)*2 = 10 azonos szenzort tudok rákötni. Nekem ez elég. Továbbá tudok helyi szenzorokat SPI-n is rákötni, szóval még többet tudok rákötni, mint ami szükséges.

Remélem, jól értem, hogy az 4 külön I2C busz.

Vagy RPI-re rakom:
https://www.seeedstudio.com/Grove-Base-Hat-for-Raspberry-Pi.html

Sakk-matt,
KaTT :)

"(1+4)*2 = 10"
Ez honnan jött ki?

A kapcsrajz szerint van rajta egy I2C EEPROM, és plusz a négy, párhuzamosan kötött csatlakozó.
EGY I2C bementen osztoznak.

Az egészet rányomhatod a procilapra, és violá, forrasztás nélkül gondolkodhatsz, meddig viheted el a drótokat.

Igen, ezt benéztem, megnéztem a Wiki oldalát és ott derült ki, hogy 4x I2C interface és nem 4x I2C busz, amit szerettem volna. Keresem tovább az I2C busz kiegészítőt ide, és akkor meg van oldva elméletben a hardver része.

Eddig ez van:

I2C Hub 1 to 6 Expansion Unit (TCA9548A)
https://m5stack.com/products/pahub-unit

"PaHUB, is a expander for I2C GROVE PORTA(red port on M5Core). 1-to-6. If you want connect mutiple I2C slave devices and some of them may sharing the same address, this unit can resolve I2C address conflicts.

At the Unit PaHUB's heart is an TCA9548A produced by TI. The TCA9548A device has eight bidirectional translating switches that can be controlled through the I2C bus. The SCL/SDA upstream pair fans out to downstream pairs, or channels. Any individual SCn/SDn channel or combination of channels can beselected, determined by the contents of the programmable control register.

Technically this Unit allows mutiple levels of nesting, for example you can wire PaHUBs to the root PaHUB to get more seats for your I2C slave devices, if you have 7 of them you can have up to 36 I2C GROVE ports, which makes it easier to get your project more organized.

The I2C address of this unit is 0x77 (changable by resistors)."

Sakk-matt,
KaTT :)

M5stacket en is nezegettem, mert tok jo thermokamerat lehetne csinalni.

https://m5stack.com/collections/m5-unit/products/m5stickc-thermal-camera-hatmlx90640

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

További megoldás, 8 portos, nekem ez így elég lenne:

SparkFun Qwiic Mux Breakout - 8 Channel (TCA9548A)
https://www.sparkfun.com/products/14685

"Do you have too many sensors with the same I2C address? Put them on the SparkFun Qwiic Mux Breakout to get them all talking on the same bus! The Qwiic Mux Breakout enables communication with multiple I2C devices that have the same address that makes it simple to interface with. The Qwiic Mux also has eight configurable addresses of its own, allowing for up to 64 I2C buses on a connection. To make it even easier to use this multiplexer, all communication is enacted exclusively via I2C, utilizing our handy Qwiic system.

The Qwiic Mux also allows you to change the last three bits of the address byte, allowing for eight jumper selectable addresses if you happen to need to put more than one Qwiic Mux Breakout on the same I2C port. The address can be changed by adding solder to any of the three ADR jumpers. Each SparkFun Qwiic Mux Breakout operate between 1.65V and 5.5V making it ideal for all of the Qwiic boards we produce in house."

Operating Voltage: 1.65V - 5.5V
Operating Temperature: -40 - 85° C
I2C Address: 0x70 (default) up to 0x77
9x Qwiic Connectors

Ha jól értem, akkor ezzel 8 azonos ID-jű I2C eszközt tudok rá csatlakoztatni.
Tehát ha a Qwiic csatlakozóra rákötök az 1-8 portra 1-1 valamilyen busz adaptert, ami elviszi messzire az I2C-t, és vissza is konvertálja, hogy I2C szenzort rakhassak rá, akkor ezzel így 8 helyiségbe tudom behúzni az azonos szenzort.

Tehát az 1-8 portra rárakok valamilyen I2C extendert vagy CAN / ModBusz rendszert, amin van I2C, akkor működni fog?

Ilyet találtam, ami ide kapcsolódhat, de szerintem nem ez a megoldás:

SparkFun AST-CAN485 I/O Shield (24V)
https://www.sparkfun.com/products/14598

Toshiba TLP290-4 Logic Controller
I/O and Power Pins broken out into both Female Headers and Screw Terminals
Fully Populated, no soldering necessary
7-24VDC Input

"The SparkFun AST-CAN485 I/O Shield allows you to use the AST-CAN485 Dev Board with 24VDC Inputs and Outputs, a popular voltage level for industrial automation devices as well as 5v devices. By providing screw terminals, the board can easily and safely interface with I/O in a semi-permanent manner which allows for inputs, outputs, or the board itself to be swapped out. With all pins pre-populated with either females pin headers or screw terminals, setup time is minimized.

The AST-CAN485 I/O Shield provides a socket to break out all of the I/O of the AST-CAN485 Dev Board. To make a secure connection to your industrial equipment, screw terminals come pre-soldered to the board to get you up and running in no time. The AST-CAN485 I/O Shield is designed to work in the industrial 24V environment, but has a wide supply input range of 7-24V. The board comes with input reverse voltage protection with a green and red status LEDs (green means power is connected properly, and red indicates reversed power, and blocks power to the rest of the board.

Note: This board has pins that operate at 24V as well as pins that operate at 5V. Care should be taken during wiring as 24V has the potential to do significant damage to 5V circuits."

Ahogy szerintem ez sem a megoldás, mert ez is Arduino-hoz van:

CAN-BUS Shield
https://www.sparkfun.com/products/13262

CAN v2.0B up to 1 Mb/s
High speed SPI Interface (10 MHz)
Standard and extended data and remote frames
CAN connection via standard 9-way sub-D connector
Power can supply to Arduino by sub-D via resettable fuse and reverse polarity protection.
Socket for EM506 GPS module
Micro SD card holder
Connector for serial LCD
Reset button
Joystick control menu navigation control
Two LED indicator

he CAN-BUS Shield provides your Arduino or Redboard with CAN-BUS capabilities and allows you to hack your vehicle. This shield allows you to poll the ECU for information including coolant temperature, throttle position, vehicle speed, and engine rpms. You can also store this data or output it to a screen to make an in-dash project.

It uses the Microchip MCP2515 CAN controller with the MCP2551 CAN transceiver. CAN connection is via a standard 9-way sub-D for use with OBD-II cable. Ideal for automative CAN application. The shield also has a uSD card holder, serial LCD connector and connector for an EM506 GPS module. These features make this shield ideal for data logging application.

Note: A DB9 Cable is not included with this shield. Please be sure to check Recommended Products section below for a recommended cable to use with this board.

Note: This product is a collaboration with SK Pang Electronics. A portion of each sales goes back to them for product support and continued development.

Sakk-matt,
KaTT :)

Amit eddig láttam legjobb CAN BUS ismertető angolul, felirattal:

https://www.youtube.com/watch?v=YvsGuK9Up0E

Sakk-matt,
KaTT :)

Kicsit off leszek sorry.
Ha idővel el akarod majd adni az ingatlant, manualt is adsz majd mellé? :) Én kétszer is meggondolnám, hogy "házi barkács" automatizálást építsek be egy több tíz milliós ingatlanba. Félreértés ne essék, mindenki azzal játszadozik amivel akar, de épületautomatizálás terén nincs sok értelme a homemade cuccoknak. Inkább beépítek egy kiforrt, mindenki által ismert rendszert, ami nem mellesleg növeli az ingatlan értékét (pl KNX).

Jogos a felvetés.

Egyrészt igen, adok dokumentációt is majd, mert magamnak is készítek az üzemeltetésnek, karbantartásnak. Mentést a működtető rendszerekről, stb. Mindenről, offsite.

Továbbá fontos infó, hogy az ingatlan minden része megy az okos otthon vezérlő nélkül, tehát ha az egész le van kapcsolva: akkor nem lesz hőmérő / páratartalom statisztika, központilag nem tudom lekapcsolni a villanyt, stb. De működik a világítás kapcsoló, redőny kapcsoló, stb. Tehát hagyományos lakásként fog működni. Ha (elromlik vagy) lekapcsolod a KNX-es lakásodban a KNX-et, akkor nincs világítás, redőny, stb, mert minden gyenge áramon megy és nem tudod gyorsan megoldani hogy átkössed a kapcsolókat erősáramra. Ez a fő ok, amiért nem KNX lett. Ez az általam "hibrid okosotthonnak" nevezett megoldás pedig nem elterjedt.

A másik, hogy ezért próbálok kész modulokból legózni, és veszek ha minden oké plusz darabokat, ha bármi elromlik, egyszerűen kihúzom és cserélem, mint a hot swap-es HDD-t :)
Másrészt nem tervezem eladni, de bármit hozhat a jövő.

Sakk-matt,
KaTT :)

Egyetlen SPoF van KNX esetén: a táp. Nem egy nagy kaland kicserélni. Áramszünet gyakrabban van, mint KNX táp hiba.

Párhuzamos rendszernek én nem látom értelmét, hiszen pont azért van az automatizálás, hogy használva legyen. Komplexitást jelentősen növeli, emiatt a költséget is. És mondjuk nem tudod kihasználni azt, amit például egy KNX alapú rendszer tudna biztosítani (elég sokféle KNX buszra köthető kapcsoló van, akár beépített termosztáttal, kijelzővel).

(közben láttam az i2c irományodat: nem értek az i2c-hez és az ott alkalmazott dolgokhoz, de ránézésre is túl bonyolultnak tűnik, rengeteg mindenféle kötődoboz és egyéb vacak kell mindenfelé, hiba esetén baromi körülményes lesz bármit is felderíteni)

mintha lenne egy kiforrott gyarto....

A leheto legrosszabb befektetes az okosotthon. Az eletbe nem terul meg.
Ha 10+evben gondolkodol, akkor valoszinu a gyarto is megszunik ahonnan vetted, vagy a termekvonalat szuntettek meg.
Kb. mint az okosTV, vagy eppen okos huto.

Egeszen mas mindset, ha eladasra epitesz. Nem epitenek be pl millio folotti nyilaszarot, nem lenne egy csomo olyan dolog, ami lett.

Legjobban egy custom rally autohoz hasonlitanam....

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Értem, köszönöm a hasonlatot.
Én is értem, érzem, hogy ez egy prototípus jellegű projekt.
Igazából az árult termékek egy jelentős része egy támogatás nélküli prototípus projekt, kevés területen van megoldva a hosszú távú támogatás. Sőt, az a gyártó, aki meg tudná oldani a hosszú távú támogatást, az sem oldja meg, csak ritka esetekben és konkrét igények esetén. Ilyen a világunk, hogy jönnek a termékek, és jönnek még újabbak, a régieket pedig már nem támogatják.

Sakk-matt,
KaTT :)

A KNX nem egy gyártó, hanem szabvány. Sok gyártó készít rá eszközöket. Nem olcsó, az is igaz. De tényleg működik, ha valaki ismeri, nem kell vele sokat vacakolni.

Igen. Az összes komolyabb kapcsoló gyártó cég csinál KNX-es megoldásokat is. A KNX-es vezérlőegységek igen költségesek tudnak lenni.
Továbbá nem ajánlott egy magyar okos otthon építő sem olyan megoldást, hogy hibridként is működjön, KNX nélkül is a világítás, azonos kapcsolóval, stb.
Mindegy, KNX jelenleg nem szerepel az opciók között.

Sakk-matt,
KaTT :)

Ennek a hibrid dolognak akkor van szerintem létjogosultsága, ha barkács rendszer lesz, amihez rajtad kívül senki nem fog tudni/akarni hozzápiszkálni (dokumentáció nem sokat fog érni adott helyzetben, ebben biztos lehetsz, mert ahhoz nagyon sok ismeretet le kellene írni, hogy valaki nulláról tudjon vele kezdeni valamit).

De ha nem barkács rendszer van, hanem valami kerek megoldás, akkor ez a hibrid olyan, mintha autód elé kocsi rúd tartót szeretnél szerelni, hátha lóval is szeretnéd valamikor vontatni. (arra nem gondoltál, hogy miért nem ajánlott senki hibrid megoldást?)

Egyébként vannak már ingyenes és olcsóbb vezérlő szoftverek is, amik tudnak KNX-szül, bár azokat még nem próbáltam.

egy knx-es kapcsolo arabol kihozza az egeszet KaTT.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Költői túlzást is elfogadva olyan kapcsolót megközelítőleg sem fog összehozni saját kezűleg (sem funkció, sem design), ami annyiba kerül.

Földhöz ragadtabban kétlem, hogy ~10-15e-ből a rendszerének akár a töredéke is kijönne.
És akkor a ráfordított időt (fejlesztés, majd üzemeltetés) sehogy nem számoltam. Ez most nyilván hobbi, de meglehetősen időigényes. Például ez a hibrid felállás a kapcsolókra minden, csak nem egyszerű, legalábbis nem tudom túl könnyen elképzelni.
Ha a vezérlést/integrációt is maga szeretné megírni, netán valami család által is használható felületet alkotni, akkor konkrétan brutális méretű a projekt. Az már nem hobbi, hanem több hónap fizetés nélküli szabadság. Persze lehet, hogy hozzá tudja kapcsolni valami kész szoftverhez, nem tudom.

"Földhöz ragadtabban kétlem, hogy ~10-15e-ből a rendszerének akár a töredéke is kijönne."

Nem lesz olcsó, csak olcsóbb, mint a legkomolyabb irodaépületekbe szánt okos otthon vezérlés. Aztán vagy így lesz, vagy nem.

Láttam multiroom audió megoldást, ami 600-900 ezer Ft, ami fantasztikus módon egy Intel Atom vagy gyengébb Pentium procis alaplapba rakott 4-6 legolcsóbb hangkártyát jelentette, és volt hozzá egyedi szoftver és felület. Aztán ennél drágábban már erősítő is volt benne.

Én most ezt a multiroom audiót összerakom Raspberry Pi alapon kezdésnek 3 helyiségbe helyiségenként kb 35e Ft-ért, mindenhol erősítővel. Erősítő nélkül még olcsóbban. A központi RPI-ről lehet vezérelni, hogy hol mi szóljon, UTP kábelen lesznek összekötve switch-en keresztül. Van sok szoftver, most tesztelem majd, melyik felülete a legjobb erre.

Innentől meg nem kérdés, hogy a többi részét is megoldom valahogy, csak kérdés, hogy mennyire kész megoldások lesznek.

Az eszközök kész, vehető termékek, az RPI-hez való erősítő is, de a vezérlő szoftverek vagy 10+ fajta egyéb erősítőt, DAC-ot támogatnak, szóval nincs gond, ha ami volt, eltűnik és nem gyártják többet, a többi is hasonló. Itt nem érzek kockázatot, hogy más ne tudná üzemeltetni vagy megérteni. Faék egyszerű csillagpontosan, RJ45-ön switch-en át bekötött RPI-k, rájuk tervezett erősítővel, és egy vezérlő RPI, mint bónusz.

Sakk-matt,
KaTT :)

Én nem a multiroomra értettem, hanem az automatizálásra. A multiroom teljesen más tészta.

> Földhöz ragadtabban kétlem, hogy ~10-15e-ből a rendszerének akár a töredéke is kijönne.

Persze gyartotol fugg, de:
szimplakapcsolo 25kHUF, duplakapcsolp 36kHUF

Kulso homero 198kHUF
Kozpont (home szerver) 700kHUF
Vilagitas vezerlo 70kHUF
Tapegyseg 130kHUF
dimmer 70 kHUF
termosztat 100kHUF

Nem is ertem, hogy tudod ajanlani.
Neked ez van az otthonodban?

Ennek is megvan a celpiaca de ketlem, hogy a lakasok es csaladi hazak lennenek azok.

Jah igen, a kabelezes egy agyrem.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Igen, az ilyen jellegű árak miatt döntöttem úgy, hogy nekem elvből nem ér ennyit ez. Továbbá ilyen eszköz alapon nem javasolták nekem a tetsző koncepciót, ezt a hibrid, erősáramú impulzus kapcsolást.

Biztosan működik, jó, stb, de más a célcsoportja, mint én.

Sakk-matt,
KaTT :)

Igen, KNX alapú rendszerem van, de ezek az árak nem pontosak, mert (sokkal) olcsóbb eszközök is vannak. Továbbra sem állítom, hogy bekerülése olcsóbb, mint egy barkács megoldásnak, de közel sem kell annyit küzdeni vele + más is hozzá tud szagolni, ha úgy hozza a sors.
KNX mellett vannak más automatizálási platformok is, több gyártó specifikus megoldás is van.

Én nem ezt ajánlottam, hanem erről mondtam el, amit tudok. Azt ajánlottam neki, nézzem meg kész megoldást, mert ott már sok kört lefutottak, sok problémát megoldottak. Bekerülési ára jó eséllyel egyiknek sem lesz olcsóbb, de van rá esély, hogy jobb lesz és nagyságrendekkel kevesebb ideje megy el rá (+ ha eladja a házat, akkor tud ajánlani egy céget, aki hajlandó a rendszerrel foglalkozni; vagy ha nincs otthon, a család is elboldogul stb., hosszan lehet ragozni).

Egyébként nem értem, miért ne lehetne bármit ajánlani? Ez kicsit olyan, mintha eretnek lenne a HUP-on "márkás" tárolót ajánlani PC alapú home-made fürtözött NAS helyett (sok helyen sántít ez az analógia, de azért van hasonlóság).

KaTT kolléga rendszere nekem túl bonyolultnak tűnik (pl. egy érzékelő és a központ között rengeteg kütyü van). Minél egyszerűbb valami, annál nagyszerűbb.

"Ennek a hibrid dolognak akkor van szerintem létjogosultsága, ha barkács rendszer lesz, amihez rajtad kívül senki nem fog tudni/akarni hozzápiszkálni (dokumentáció nem sokat fog érni adott helyzetben, ebben biztos lehetsz, mert ahhoz nagyon sok ismeretet le kellene írni, hogy valaki nulláról tudjon vele kezdeni valamit)."

Helyiségenként a lámpa impulzus kapcsolókkal megy, az impulzus relé csillagpontosan egy külön helyen van, és az okos otthon is tudja kapcsolni így a lámpát. Nyilván aki egy villanykörtét is csak harmadjára tud jól kicsavarni, annak ez túl sok. De neki a KNX alapú rendszer is dettó sok, és akkor az okos otthon szerelőt kell hívnia, nem akármelyik villanyszerelőt, aki kicseréli neki az esetlegesen elromlott impulzus relét a Din sínről egy mozdulattal.

"De ha nem barkács rendszer van, hanem valami kerek megoldás, akkor ez a hibrid olyan, mintha autód elé kocsi rúd tartót szeretnél szerelni, hátha lóval is szeretnéd valamikor vontatni. (arra nem gondoltál, hogy miért nem ajánlott senki hibrid megoldást?)"

Nem akarlak meggyőzni a redundancia szépségéről és a biztonsági másolat készítésének értelméről, vagy hogy RAID 1 mirror esetén is a biztonsági másolat nem felesleges dolog, főleg ha offsite backup és rendszeres.

Ez a példád így nem pontos. Az talán jobb példa, hogy olyan szerver PC-t veszek, amiben kettő, redundáns tápegység van, és ha az egyikkel történik valami, a másik akkor is működik, leállás nélkül, és tudom a hibás tápot cserélni menet közben. Te pedig inkább azt mondod: nem kell redundáns táp, majd ha elromlik, ahogy lehet cseréljük, de hát egy milliós szerver nem romlik el soha, ugye? Az, hogy üzemidő kiesés lesz, adatvesztés, nem fontos és nincs felkészülve rá a rendszer. Pedig lehet ilyen. Erre azt fogod mondani, hogy ezek szinte soha nem romlanak el, de ha mégis, akkor pedig pont akkor, amikor amúgy is épp cseréltek volna valamit és üres a ház. :-) Egy jobb sales-es ennél sokkal jobbat is ki tud találni, hogy szinte még jó is, ha elromlik néha... :-)

Ha ez a hibrid okos otthon rendszerrel történik valami, akkor az okos funkciót elveszítve is megy tovább az élet. Ha egy impulzus relé tönkre menne, akkor a helyiség 2 vagy több fényforrásából csak az egyiket nem lehet felkapcsolni. Na bumm. Ha kiég az égő most, akkor sem világít, és túléljük. Ha mondjuk az összes izzó égne ki sötétedés után, péntek este, az már nagyobb gond lenne.

Ha veszek egy 8 csatornás KNX vezérlőt, és a lakás összes lámpája ezen van, és ezzel történik valami... akkor sehol nincs világítás, elő a gyertyát vagy zseblámpát. Nyilván én úgy csinálnám, hogy több ilyen vezérlő lenne, és a helyiségekben 2 fényforrás lenne, mind a 2 külön vezérlőn, így ha az egyiknek vége, akkor a másik majd csak menni fog. Ez persze plusz költség, de megérné.

A kész, gyári megoldású okos otthonok növelik a lakás értékét, főleg az okos otthont kiépítő cég szemében... :-) Az új vásárló pedig kap egy drága, belálthatlan karbantartói költségű valamit, amit a másik okos otthont építő cég azonnal áttervez, mert szarul csinálta meg az előző nyilván, mindent kicserélve szinte ingyen megcsinálja ugyanazt...

Ebben a hibrid rendszerben pedig ha nem égnek el a jóval nagyobb áramot is elviselő erősáramú, réz kábelek, akkor egy mezei villanyszerelő is ki tud cserélni egy relét, vagy esetleg egy kapcsolót (az oda írt és lerajzolt dokumentáció esetén, az oda készített új, bontatlan azonos alkatrészekből), ami töredéke az okos otthon üzemeltetésnek. Bár mondjuk a JUNG kapcsolók nem annyira szoktak elromlani... Az impulzus relénél 200 ezer kapcsolást garantálnak 16A esetén, ami napi 10x kapcsolás után is 50+ év. Ha elromlik az okos otthon vezérlés? Ha a RAID 1-es NAS-sal van valami, akkor HDD vagy SSD csere, és visszaállás a mellékelt backup-ból, ha mind a 2 HDD/SSD halott, ha csak az egyik, hotswap, csere és megállás nélkül oké (hiszen jött figyelmeztetés a SMART alapján). Ha a NAS nem megy? Kicserélni egy hasonló típusra és visszaállni a dokumentált paraméterekkel a biztonsági mentésből. Ha központi RPI halt meg? RPI csere, visszatölteni a leírt módon a biztonsági mentésből és megy minden. Ha egy multiroom audió romlott el? RPI csere, vagy erősítő csere (audió kábelek ki, 4 csavart ki, régi lehúz, új visszarak, 4 csavar be, audió kábelt vissza), minden RPI a NAS-ról megy, így azok mentve vannak. Ha egy szenzoros Arduino / ESP / RPI megy tönkre: elő +1 a készletből és visszaállás a leírt módon. Kész.

Ezt a visszaállást, RPI vagy RPI erősítő cserét egy IT-ra fogékonyabb 16 éves lehet, hogy csak részleges dokumentáció olvasás után is meg tudja csinálni, szórakozásból. Mivel azonban saját célra készült, így a környezetemben többen ezt meg tudnák csinálni ha szükséges.

Sakk-matt,
KaTT :)

Hát ebben erőteljes csúsztatás van:
- informatikában nem a maximumhoz igazítjuk a rendelkezésre állást, hanem az elfogadható kockázathoz
- egy szerver RAID1-gyel sok helyen annyi, mintha semmi nem lenne: minimum redundáns tároló, több szerver, vagy megfelelően fürtözött szoftver, alatta/előtte redundáns hálózat
- egy házat elég nehéz bármekkora céggel, főleg általánosságban összehasonlítani

Nem látom, hogy egy "gyári" megoldás karbantartási költsége miért lenne beláthatatlanabb. Inkább fordítva látom: ha nem leszel ott, kérdés, hogy egy laikus honnan akaszt le valakit, aki hajlandó hozzányúlni és megcsinálni (barkács megoldást jobb eséllyel cserél le). Van/volt több ilyen-olyan kisebb házi projektem, baromi nehéz megfelelő szakembert találni: nem a jelenlegi gazdasági helyzet miatt, hanem azért, mert ami nem megszokott háztáji megoldás, az tipikusan ipari, és ott a dobozos dolgok egy házhoz mérten a csillagokban vannak (ha egyáltalán alkalmazhatók) és az azzal foglalkozóknak nagyon nem éri meg ilyen léptékkel foglalkozni (nem is feltétlenül az a kérdés, hogy meg tudod-e fizetni, egyszerűen kicsi a projekt és nem éri el az inger küszöböt - meg is tudom érteni, én sem szeretek minden vacakkal foglalkozni, mert nem éri meg).

A világításon kívül fontosabb lehet a fűtés/hűtés, ahol a párhuzamos működést még kevésbé érzem racionálisnak.

Nemcsak olyan hiba lehet, hogy valamit ki kell cserélni. A hibát meg is kell találni.

A többi túlságosan szubjektív, nem akarlak semmiről meggyőzni, csak jeleztem azt, amit én tapasztaltam, ez a felállás nekem túl bonyolultnak tűnik. (szerintem barkács módon is egyszerűbben lenne célszerű, de sok mindenhez nem értek ebben a témakörben, ami alapján konstruktívabb választ is tudnék adni)

Szia, értem, köszönöm a válaszodat. Tanulságos olvasni ezt egy másik szemszögből.
Nyilván a nem gyári megoldás esetén nehezebb karbantartót találni. Mivel ez saját célra készül és hosszú távra, így alapvetően én fogom karbantartani a gyengeáramú részt biztosan. Ha eladásra kerülne, az is egy külön téma, de nyilván ezt is figyelembe vettem. Én úgy csinálom meg, ha én akarnám megvenni, akkor mit várnék el, hogy legyen megoldva, megtervezve, dokumentálva. Aztán kiderül, hogy ez mire elég.

A hűtés / fűtés vezérlés és párátlanítás egy későbbi téma. Első körben csak a mérések készülnek el és hozzá a grafikonok.

Sakk-matt,
KaTT :)