JxxxIxxx

Jeg ser at jeg har gjort en feil i lista over devicer, Popp-pluggen ble aldri installert, hadde tenkt å bruke den på noe julelys, men den ble alrdi lagt til i nettet, så det er i alle fall ikke den som er synderen 🙂 Min feil at jeg tok den med i lista. Ellers så har jeg en slik bryter også i min andre HS installasjon (hjemme) og der har den fungert helt stabilt, også tilsynelatende som router/repeater, nettverket ble faktisk merkbart bedre på noen marginale noder med dårlig dekning når jeg plasserte denne på et egnet sted. Derimot hadde jeg tidligere en Popp-plugg av den eldre varianten (009105) som ser helt identisk ut. Denne oppførte seg ved et par anledninger litt psykotisk ved lave temperaturer og ble pensjonert og arkivert under bomkjøp.

OK, det var ikke oppløftende lesing. Jeg har vel kanskje en eller to av disse eldste (de med den store rektangulære "klumpen"), men de fleste er den nyere og mye mer kompakte modellen. Jeg har ikke dårlige erfaringer med disse som jeg kan huske, har hatt noen/de fleste i 3 år minst. Har noen i den andre HS-installasjonen min også (hjemme). Men de er ikke i kritiske eller mye brukte funksjoner, ingen i varmeovner som blir slått mye av og på f.eks. Har ikke merket så veldig mye trøbbel (bank i bordet). Jeg hadde en som bare sluttet å virke og så var det en som jeg mistet kontakten med et par ganger, men som kom tilbake når jeg tok den ut av kontakta og satte den inn igjen. Den ble uansett fjernet, gidder ikke å ha upålitelige enheter, spesielt hvis svikt medfører at jeg må kjøre to timer (hver vei) for å få frostvakta på hytteboda til å fungere igjen. Statistisk sett har jeg faktisk prosentvis hatt flere Aeotec-plugger som har sviktet. Jeg har ikke så mange av disse, men to har "dødd" så langt. Skjønner at jeg bør kanskje prøve å skifte dem ut, men det skjer ikke umiddelbart, må skaffe erstattere og det blir ikke billig. Har et par av de nyeste Aeotec-pluggene liggende som jeg ikke har tatt i bruk ennå, så kan vel begynne med å erstatte noe i alle fall.

En omtrentlig liste med Z-wave enheter: I tillegg til de to Popp-røykvarslerne og 4 stk Z-trm2fx og en Z-Temp2 har jeg: Noen strømplugger/brytere: 2 stk Aeotec ZW096 6 stk Telldus, tror de fleste er 313510 2 stk Nexa AN-180 1 stk Popp 700397 Noen av strømpluggene er ikke i bruk til noe, de er bare utplassert som repeatere for å bedre dekningen. 1 stk Aeotec repeater 4 stk Aeotec multisensor (gen 6) 2 stk Fibaro røykvarslere 3 dørsensorer (Aeotec ZW112 og Fibaro FGK-10x) 4 stk Nexa Lysbrytere (AN-179) 2 stk trådløse brytere (wall controller) usikker på merke, minst en er Namron 1 stk temperatursensor, Cleverio 1 stk bevegelessensor, Nexa 1 stk lekkasjesensor, husker ikke merke i farta (trolig Fibaro) Det er kun Z-temp2 som er satt opp med assosiajoner (til to Aeotec strømplugger). Ikke relevant for denne saken, men ellers så har jeg en del 433 mHz temperatursensorer og litt Zigbee-utstyr (Lys og sensorer)

ikke så mange, det er 38 noder ifølge Z-wave Node Information.

Logget til debug i bortimot en og en halv time. Ser ikke noe unormalt egentlig. To av fire Heatit Z-Trm2fx termostater til varmelkabler i kjeller var litt pratsomme med cirka 900 aktiveringer på denne tiden. Fant ut at de var satt til å rapportere temperatur en gang i minuttet, det er vel ganske unødvendig, så har redusert dette kraftig. ellers er det ingen som peker seg ut som spesielt aktive.

Har bare to så det burde være innafor, lurer på om maks var 5?

Dette var min egen konklusjon også. Greit å vite at andre med mer kompetanse enn meg konkluderer på samme måte. Jeg har gjort dette for de fleste Z-wave-nodene, men ikke alle ennå. Har ikke funnet noe som ikke skal være der så langt. Primærmistenkt når det gjelder assosiasjoner er jo Heatit Z-temp2, som jo faktisk er satt opp med assosiasjon til to strømplugger. Men denne har bare assosiasjon til de to den faktisk skal styre, og tidspunktene for når feilen har oppstått stemmer ikke overens med når termostaten har slått inn. Jeg mener å ha lest en gang noe om at det finnes en "All ON"-kommando i Z-wave. Er det tenkbart at en eller annen node kan av ukjente grunner ha sendt ut noe slikt? Ser at en del Z-wave-brytere har en konfigurasjonsparameter som besttemmer om bryteren skal reagere på slike kommandoer eller ikke. Men ikke alle har denne konfigurasjonsmuligheten tydeligvis. Vet ikke om dette er noe legacy-greier på eldre Z-wave brytere? En annen ting jeg har lagt merke til når det gjelder Popp-røykvarselerne er at i dokumentasjonen så står det at de "will, without further configuration, notify other smoke sensors and sirens of the same type when an alarm occurs". Altså at de tydeligvis prøver å sende kommandoer via Z-wave til andre røykvarslere dersom noe skjer. De sender både dersom en røykvarseler løser ut og også ved lav batteristatus, tydeligvis. Det kan jo tenkes at slik kommunikasjon har kommet på villstrå. Det som taler i mot at problemet kan noe med dette å gjøre er at røykvarslerne ikke har løst ut og batteristatusen er stabil på 100 prosent (de er også på egen 12 V strømforsyning, batteriet er bare backup ved strømbrudd). I følge manualen er det mulig å slå av denne kommunikasjonen til andre røykvarslere vha to konfigurasjonsparametre. Jeg har nå slått av dette, så får vi se om det har noen effekt. Problemet er at systemet må tydeligvis kjøre i ukesvis før jeg kan være rimelig sikker på at dette ikke skjer lenger. Dette har i gjennomsnitt bare skjedd mindre enn en til to ganger i uka til nå. Jeg får vurdere å prøve å slå på debugging log i en periode. Litt usikker på hvor store filer den genererer. Selve problemene skjer ikke veldig ofte, og jeg antar denne loggingen ikke bør stå på i mange dager. Har testet dette tidligere i korte perioder bare fordi jeg var nyskjerrig og den gangen fant jeg ingen synlige problemer.

Takker for svar. Jeg tror jeg har kontroll på assosiasjoner på alle devicer ja, og ser ingenting suspekt der. Jeg har ellers ingen dimmere, hverken Fibaro eller annet i systemet. Har vel ingenting Fibaro i et hele tatt tror jeg.

Usikker på om dette hører hjemme under Homeseer eller under Z-Wave, men legger det her under HS foreløpig: Jeg har en HS3 installasjon på hytta, primært for å fjernstyre oppvarming, men har også forskjellige andre funksjoner, som utelys, røykvarselere, noen kamera etc. Z-Wave controller er UZB1. I de siste 3-4 ukene har jeg opplevd flere ganger at en eller flere Z-wave-brytere i systemet tilsynelatende slår seg på "av seg selv". Dette har så langt skjedd kanskje en 5-6 ganger over en 3-4 ukers tid nå. Første gangen oppdaget jeg det tilfeldig ved at jeg så på et kamera jeg har installert at noen av utelysene var på når de ikke skulle være det. Har nå lagt inn en del eventer som varsler meg dersom visse brytere blir slått på når vi ikke er der, så jeg tror nå jeg har fanget opp alle gangene dette skjer. Symptomene er omtrent som følger: - Når det skjer så er det som regel flere noder som slår seg på samtidig. Ikke alle Z-wave brytere, men flere. Ikke alltid de samme. I dag tidlig slo en 13-14 noder seg på samtidig. En av gangene var det bare en enkelt bryter. De fleste gangene har det vært en 5-8 noder. - I følge loggen slå alle seg på samtidig, innenfor ett sekund. - Det er alltid ON, aldri OFF. - I loggen står det for hver node (dersom logging er slått på for den devicen) en enkelt linje av type "Z-Wave" med en tekst omtrent som "Device: xxxxx set to ON". Dette er forskjellig fra dersom jeg manuelt eller via en event slår på en bryter f.eks via myHS eller via JSON eller HSBuddy, da er det to eller tre linjer i loggen. Denne linjen i loggen ligner mer på det som skjer dersom en bryter blir slått på fra en annen device, dvs.f.eks en plugg er assosiert til en termostat og slår seg på når termostaten går til ON på heating. - Det er stort sett bare lysbrytere eller strømplugger som slår seg på, men flere av gangene har sirenen på en av Popp-røyvarselerne slått seg på også, dette er jo også en on-off-device. Selve røykvarseleren er ikke utløst i disse tilfellene. - Det virker fra loggen som noen av bryterne har fått ON sendt til Root device og ikke til bryter-devicen. Ut fra det som skjer så kan det virke som om en eller annen Z-Wave node sender tilfeldige ON-kommandoer ut i nettverket. Jeg har gjort relativt få endringer i nettverket i det siste. Men for en stund siden (ca en uke før dette skjedde første gang) installerte jeg to stykk Popp røykvarslere (type 00401, ikke den nye modellen). Disse er derfor primær-mistenkte. Jeg har i flere år hatt to røykvarslere av akkurat samme type i min HS-installasjon hjemme, uten jeg har registrert noen lignende problemer der. Før jul byttet jeg ut min gamle Secure SRT-321 termostat med en Heatit Z-temp2. Denne er assosiert til to Aeotec veggplugger. Men problemene i hytte-systemet begynte tilsynelatende først mellom en og to måneder etter at jeg installerte denne termostaten uansett (tror jeg i alle fall, det kan jo være at ting har skjedd tidligere uten at jeg har registerert det). Jeg har to av samme termostaten i min HS-installasjon hjemme og har som tidligere sagt ikke opplevd noen tilsvarende problemer i dette systemet. Det begynner nå å bli litt slitsomt å ha disse "tilfeldige" hendelsene i netverket, jeg kan jo ikke stole på noe lenger. Dette er spesielt foruroligende ettersom dette er i en installsjon som er lagd primært for fjernstyring, så man bør helst kunne stole på at systemet fungerer. Så langt har dette skjedd mens vi ikke har vært til stede på hytta, men hvis dette skjer mens vi er der og sirenen på røykvarselerne slår seg på så blir det jo litt oppstuss også. Jeg har en i familien som blir rimelig stressa dersom røyvarslerne begynner å pipe, så dette kan fort gå ut over WAF. I tillegg er det ganske slitsomt at brytere på diverse ting lever sitt eget liv. Heldigvis er det alltid ON og ikke OFF, hvis ikke kunne de potensielle konsekvensene vært mer omfattende, uten at jeg skal gå i detaljer på det. Eventuelle råd og forslag mottas med takk. Det første jeg vurderer er å ta vekk igjen de to Popp-røykvarslerene og se om problemet da forsvinner.

Tilleggs-info: Jeg søkte litt tilbake i gamle tråder på forumet og fant en tråd fra 2017 fra da jeg hadde problemer med SRT321 og HS Z-Wave plugin som hadde en bug. Akkurat det ordnet seg etterhvert, men jeg ser at jeg skrev følgende etter at det hadde løst seg: "Man må også huske på å sette polling i HS-devicen for setpoint til et intervall kortere enn wake-up-perioden på termostaten, hvis ikke blir ikke nytt setpoint satt fra HS oppdatert i HS-devicen etter at termostaten har "våknet". Jeg vet ikke om dette gjelder fortsatt (og kan som sagt ikke sjekke det etter som jeg ikke har termostaten i nettverket lenger). Jeg ser at på V5-versjonen av termostaten er det ikke satt noe polling-intervall hos meg, men det trenger ikke bety annet enn at de fungerer på forskjellige måter når det gjelder dette også.

Å sette setpoint fra HS har fungert fint hos meg, men det tar tid. Setpoint oppdaterer seg ikke før termostaten "våkner opp" og kommuniserer med HS. Og det skjer ikke så ofte, synes å huske at default var 15 minutt. Så vidt jeg kan huske er dette konfigurerbart, men husker ikke detaljene. Jeg tror jeg satte mine til 7 minutter. Hvis jeg derimot endrer setpoint med å dreie på hjulet på termostaten så oppdaterer HS seg umiddelbart. Jeg kan ikke sjekke hvordan min termostat av samme type (ikke v5) er satt opp når det gjelder assosiasjoner, da jeg fjernet den for omtrent en måned siden og erstattet den med en Heatit Z-Temp2. Jeg har en SRT321 (versjon 5) i drift på hytta, men har tenkt å bytte ut den også.

Beklager sent svar, ser at du fant ut av det selv. Og så vidt jeg kan huske gjorde jeg samme feilen når jeg prøvde å inkludere den første.

Nå ha det gått stabilt i over to døgn. Jeg poller 6 registre hvert 30.sekund med et delay på 2.5 sekunder mellom hvert register. Det er tydligvis dette siste som har vært avgjørende for at mitt oppsett skal gå stabilt. Når jeg polla registerne for tett etter hverandre krasja det etter en stund. For sikkerhets skyld kommer jeg til å sette strømforsyningen til Modbus-adapteren på en ZWAVE-bryter og lage eventer som gjør at jeg kan disable plugin'en og slå av adapteren og enable pluigin'en og slå på igjen adapteren. Da har jeg i alle fall muligheter til å stoppe/resette hvis det skulle oppstå en feilsituasjon. En annen funksjon som kunne være nyttig for meg er å få HS til å gi meg et varsel når det nærmer seg tid for å bytte filter. Jeg ser i Modbus-dokumentasjonen for aggregatet at det er register for gjenstående tid før filterbyte, angitt i antall sekunder (!) (hadde ikke dager vært mer enn godt nok?). Men gjenstående tid er delt opp i to register, "lower 16 bits" og "higher 16 bits". Er det noen som kan gi meg et tips på hvordan jeg enklest kan slå disse to sammen til en device som har gjenstående tid som ett enkelt tall (fortrinnsvis i dager)?

Det stemmer at jeg ikke behøver å polle så ofte for de registerne jeg bare leser. Men det er noen register ikke bare er read-only, de lar meg styre aggregatet (viftehastighet, såkalt "user mode" og noen andre parametre), og med en lav pollefrekvens vil det ta tid før det reagerer. Dette er i seg selv ikke så kritisk dersom det bare er snakk om noe jeg styrer basert på schedule/tid/tilstand, f.eks. skru ned eller opp vifterhastighet morgen/kveld eller basert på om det er noen hjemme eller ikke. Men jeg hadde f.eks. også en ide om at jeg kunne installere en knapp på badet som man kunne trykke på før man dusjer og som gir en 15 minutt "boost" på ventilasjonen. Men når jeg tenker meg om så er det vel ikke kritisk om dette gir umiddelbar respons heller. Så ja, det er vel kanskje ikke nødvendig å polle hvert 10.sekund. Men i den opprinnelig guiden var det en verdien som var brukt og i følge @Moskus hadde Systemair sagt at man kunne polle hvert sekund om man ønsket. men dette fungerer tydeligvis ikke hos meg.

Nå har den gått feilfritt i 15 timer med polling av ett register annethvert sekund, så det er jo lovende. Men lar den gå i alle fall til i kveld før jeg føler meg trygg på at det er stabilt. Hvis dette er stabilt så antar jeg at jeg kan polle mer enn ett register hvis jeg passer på at "Delay between each address poll" er minst 2 sekunder? (må da også naturligvis øke tiden mellom hver poll tilsvarende). Dette betyr vel at dersom jeg f.eks. poller hvert 10. sekund med 2 sekund delay mellom hvert register så kan jeg ikke polle mer enn maks 5 forskjellige register.

Ok, slo på igjen adapteren, og enablet plugin igjen. Disablet alle register-devicer unntatt en og satte poll til 2 sekunder. Foreløpig ingen feilmeldinger.

Fem timer gikk det, så krasja det igjen, samme feilmeldinger. ☹️

Det er jo det jeg må prøve hvis ikke annet virker, men jeg er vel ikke så motivert til å bruke tid på sette meg inn i enda flere for meg ukjente teknologier. Jeg er også usikker på hvor jeg skal lete etter problemet. Slik jeg forstår det kan det være et problem mellom HS og adapteren, eller et problem internt i adapteren, eller i kommunikasjonen mellom adapteren og aggregatet. Det er en del ting som tyder på at det er det siste (se under). Etter min forrige mislykkede test med IAM-adapteren som Modbus-adapter, satte jeg i går kveld denne tilbake til Cloud og slo på igjen USR-TCP232-410S adapteren og omkonfigurerte HS igjen til å bruke denne. Også nå skjedde det samme som tidligere, den virket umiddelbart, men etter en stund (kanskje en time, jeg fulgte ikke med hele tiden), krasjet alt og feilmeldinger haglet i loggen. Nå var det igjen ikke mulig å nå adapteren på noen måte. Jeg disablet plugin og slo av og på adapteren. Adapteren kom opp igjen og kunne nåes via nettet, men hvis jeg slo på igjen pluginen så feilet den etter bare sekunder. Dette kan kanskje tyde på det som var nevnt av noen tidligere, at adapteren "spammer" aggregatet med så mye forespørsler eller feil at det "stenger ned" Modbus-kommunikasjonen for en lengre periode. Jeg slo av plugin og adapter over natten og slo dem på igjen i dag tidlig, og da virket alt igjen. Denne gangen endret jeg på noen parametre. Jeg satte "Delay between each address poll" til 500ms (default er 0). Jeg stilte også om baud rate i adapter og aggregat fra 115200 til 9600. Mulig akkurat dette siste ikke er helt lurt, men tenkte å gjøre kommunikasjonen litt mindre "følsom". Adapteren er koblet til aggregatet med en 12-15 meter lang CAT6 nettverkskabel, på samme måte som vist i guiden. Vet ikke hvor følsom Modbus er for lengder og type kabel. Uansett så har jeg nå alt oppe å gå på tredje timen uten feilmeldinger, noe som er lovende. Men det er ikke nødvendigvis sikkert problemet er løst. Tross alt så virket alt i nærmere et halvt døgn den aller første gang jeg prøvde, så vi får se hva som skjer over tid nå. Jeg har nå definert devicer mot 6 ulike register, så pluginen poller aggregatet 6 ganger hvert 10.sekund. Alt fungerer tilsynelatende som det skal, verdier oppdaterer seg hvis jeg endrer innstillinger i aggreagtets styrepanel, og jeg kan kontrollere viftenåvå og "User mode" fra HS.

For å teste stilte jeg om IAM fra Cloud til Modbus. Det var litt vanskelig å få kontakt fra HS, siden det ikke stod i dokumentasjonen hvilken port den kommuniserte på, men her i tråden fant jeg at det var 502 og da hadde jeg kontakt. Jeg hadde bare konfigurert ett register i HS (Active User Mode) for å teste. Initielt så det ut som det fungerte, devicen oppdaterte seg til riktig verdi, men så begynte feilmeldingene å hagle. Andre meldinger enn med den andre Modbus-adapteren. Error in ReadValue: Exception of type 'Modbus.SlaveException' was thrown. Function Code: 132 Exception Code: 1 - The function code received in the query is not an allowable action for the server (or slave). This may be because the function code is only applicable to newer devices, and was not implemented in the unit selected. It could also indicate that the server (or slave) is in the wrong state to process a request of this type, for example because it is unconfigured and is being asked to return register values. Så ingen suksess dette heller. Uansett så var det ikke meningen å bruke IAM som Modbus-adapter, så jeg kommer nok til å stille den tilbake til Cloud-modus, da har jeg i alle fall litt styring på aggregatet. Jeg får se om jeg orker å bruke mer tid på å teste den andre Modbus-adapteren. Jeg har egentlig ikke kunnskap nok til å vite hva jeg skal gjøre for å debugge det oppsettet og det er grenser for hvor mye tid jeg kan bruke på dette. Litt irriterende at det ser ut som jeg ikke klarer å koble aggregtet til HS, det var en de tingene jeg hadde sett fram til å gjøre når jeg likevel måtte bytte ventilasjon.

Noen av gangene hjalp det å restarte plugin'en, men ellers så kom feilene opp igjen bare sekunder etter at jeg hadde enablet plugin igjen s¨å det har ikkje vært konsistent. For øyeblikket har jeg gitt litt opp og har disablet plugin'en. Jeg mistenker også at problemet kan være en ustabilitet i mobus-adapteren som gjør at HS mister kontakten med den. Den første gangen jeg fikk problemet så var adapteren heller ikke mulig å nå via web browse eller ping eller noe annet, og jeg måtte ta strømmen på den for å få den opp igjen. Men senere har pluginen i HS feilet uten at adapteren har vært offline, jeg har kunnet aksessere adapteren fra nettleser f.eks., mens HS gir feilmeldinger, så symptomene er ikke konsistente. Jeg har en annen Modbus-adapter av en litt annen type som jeg kanskje kommer til å prøve når jeg får litt ledig tid. Jeg har også en IAM (Internet Access Module) tilkoblet aggregatet og denne kan stilles om til å fungere som en modbus adapter, men da mister jeg kontroll via app og det har jeg lyst til å beholde av ulike grunner.

Dette er det jeg kan sette i HS plugin:

Koblet til adapteren i går kveld, installerte Modbus plugin i HS3 og konfigurerte noen devicer og det gikk tilsynelatende fint. Kunne lese ut info fra aggregatet og også styre noen innstillinger. Så langt så alt lovende ut. Men i dag begynte det å halge med feilmeldinger i HS loggen, meldinger slik som dette: Error in ReadValue: Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. og Read error for Fan level Et eller annet er ustabilt, men jeg har ikkke forutsetninger for å kunne si hva det kan være. Har prøvd å restarte plugin og restarte Modbus-adapteren og det virker litt av og til i korte perioder, men så begynner feilmeldingene ganske fort og da ser det ut som alt svikter og jeg får hundrevis av slike meldinger (sannsynligvis hver gang den poller). Modbus-adapteren er satt opp slik: Det merkelige er at alt fungerte tilsynelatende fint i nesten et døgn før problemerne begynte, uten at noe er endret i systemet i løpet av den tiden.

Takker for svar. Adapteren har nøyaktig samme merke og modellbetegnelse som den som er vist i guiden, men er tydeligvis ikke helt lik. Poenget med det jeg nevnte om flow control var at valget RTS/CTS ikke fantes, det er enten XON/XOFF eller None. Men XON/XOFF er vel nesten det samme som RTS/CTS. Nå hadde jeg ikke koblet adapteren til aggregatet ennå, jeg bare koblet den opp på nettet for å teste at jeg kunne aksessere den. Vil det påvirke hva jeg ser av valg i menyene at den ikke er koblet til aggregatet? Bare det å finne adapteren i nettet var en utfordring for en amatør som meg. Etter mye om og men og den del søking fant jeg ut at adapteren tydeligvis var satt opp med en spesifikk fast IP i et adresseområde som jeg ikke kunne nå slik ruteren min var konfigurert. Heldigvis hadde jeg en gammel ruter liggende som jeg kunne endre konfigurasjon på og sette opp et lite separat nettverk med adapteren og en pc, og da fikk jeg tak i adapteren og kunne sette en mer passende IP. Hadde vært mye enklere om adapteren kom med dynamisk IP som default.

Jeg prøver å følge guiden for å sette opp Homeseer mot mitt nyinstallerte Systemair SAVE VSR300. Har kjøpt samme adapter som Moskus, men kommer ikke lenger enn til punkt 2 i guiden. Når jeg logger meg inn på adapteren så ser skjermbildet for RS485-konfigurasjon ikke likt ut med det som vises i guiden: Hos meg mangler "remote port number" , har kun ett felt for port (Local). Er det her jeg skal sette 8234? I tillegg står det XON/XOFF i stedet for RTS/CTS under Flow Control, har dette noe å si? Eller har jeg fått feil adapter, eller evt. feil firmware? Prøvde å finne og laste ned firmware, fant en link, men den feiler.

Jo, det kan du nok. Multisensor har USB-input for strømforsyning, så med en POE-splitter av den type du linker til, skal du kunne ta ut USB-strøm vha den kabelen som følger med sensoren, men i utgangspunktet bare til en enhet pr. splitter. Hvis du skal hente strøm til flere enheter fra en enkelt slik POE splitter må du vel ha en eller annen form av deling/splitter etter USB-strømuttaket igjen. Nettverkstilkoblingen på POE-splitteren trenger du ikke for Multisensor, den er Z-Wave. Jeg har brukt POE som strømforsyning på lignende måte (men med en 12V splitter) med enheter som krever 12V (og nettverkstilkobling). Til mine multisensorer har jeg ikke POE, men har trukket 12V og satt inn en 12V-til-USB konverter (f.eks. en mobillader for bil). Hvis denne har flere USB-utganger og sensorene ikke er plassert for langt fra hverandre kan du drive flere sensorer med samme 12V USB-laderen.