Mastiff

Næh. Mine Nexa er akkurat like stabile som mine Z-Wave, det er bare å gjenta signalet som sendes.

Jeg kjøpte en pakke med Nexa MYCR-3, og det viser seg at den er fullstendig ubrukelig! De er jo som de fleste tidligere strømpluggene fra den kanten, mottakelige for programmering de første sekundene etter at de ble satt inn. Ulempen med det er at hvis de er plugget ut og settes inn, vil de alltid være mottakelige hvis ikke minneplassene er fulle. Det er mye bedre med de bryterne der man må trykke inn en knapp for å programmere, så risikerer man ikke at noen tar ut strømpluggen for å sette inn en mobillader eller et eller annet og så setter den inn igjen, og så kommer det et signal til en annen strømplugg i systemet som blir tatt som programmering av den som nettopp er satt i. Men med de tidligere utgavene var det håndterbart, for da var det tre minneplasser, og man måtte avprogrammere dem manuelt (ved å sette inn pluggen og trykke off, eventuelt all off for å stryke alle tre) når disse var fulle. Så jeg har bare brukt 15 og 16 i alle seriene jeg har til å sørge for at det ikke kan skje. Men her kommer "genistreken" til Nexa: For det første har den 32 minneplasser (hvem f... trenger så mange?). Det ville blitt enormt mye arbeid å sperre de 31 minneplassene som måtte sperres for å unngå "villprogrammering". Men det blir faktisk hakket verre. For den har i tillegg et oppsett som er sånn at når den 32. plassen er brukt og dingsen er full...så overskriver den programmeringen fra plass én og framover igjen! Med andre ord er disse pluggene fullstendig ubrukelige for alle som har noen form for sentralt system som sender signaler, eller som har mer enn én fjernkontroll i sjappa, og ikke husker å si "ingen må trykke på noen knapper nå, for jeg setter inn en strømplugg"... ? Så jeg får vel kjøpe opp restlageret av Nexa PE-3, tenker jeg... Det er selvsagt greiere med Z-Wave på det området, problemet er bare prisen. Én Z-wave-plugg koster rundt 400 kroner, og for det får man seks Nexa. Så da får jeg heller holde kontrollen på hva som står på og av i selve systemet, som jeg allerede gjør.

Å, en ting til: Med den ekstra Pi-en med rfxTRX skal jeg få mer stabile temperatursignaler fra den borterste enden av huset. Med meshløsning fra Airties er ikke wifi noe problem, men på grunn av de nevnte bygningsdetaljene sliter den nåværende litt med et par temperatursensorer, som ikke når gjennom mer enn rundt hvert femte minutt.

Det går ikke, Pi-ene står på steder der det ikke er plass til noe større pga. husets utforming, med rom med fliser og ei diger mursteinspipe fra 1800-tallet. Uansett blir det jo ikke noe mer komplisert av å splitte opp sakene. Og det å sette inn en ekstra pi eller to går på en time, med kopiering av minnekortene.

Å, sorry. Jeg uttrykte meg nok litt feil der. Jeg skal ikke ta ALT over på Hass. Hvis det i det hele tatt er mulig, ville det nok vbety flere måneders arbeid for å få tilbake den samme funksjonaliteten. Jeg mente bare det som kjører på Pi-ene, altså å gjøre om kommandoer til og fra 433 mHz til MQTT-meldinger til selve styringssystemet.

Moskus, det ser ikke ut til å funke med Hass, så jeg tror jeg heller skal skille ut Hass/Z-Stick og kjøre det på en egen Pi, for Z-Wave låser seg nesten aldri (tror jeg har opplevd det én eller to ganger på halvannet år). Xibriz, så vidt jeg har funnet ut (ved å kjøre et nøyaktig likt system på hytta som aldri henger seg, og fordi det begynte å skje etter at jeg satte i drift alle tre etasjene i huset) skyldes det mengden av 433 mHz-signaler. Det er rundt 30 temperatursensorer i huset (redundans med to i hvert rom som styres av varmesystemet - hvis batteriet går tomt på den ene, sendes det en mail til meg om det, og systemet fortsetter uten avbrudd å kjøre på den andre), og i tillegg diverse brytere og strømplugger, pluss seks Heat It!-termostater på Z-Wave og en del andre ting som sender. Men Z-Wave kjører på Hass, mens 433 mHz kjører på Node-RED. Jeg vurderer å sette alt over på Hass for å se om det hjelper, men det er litt mer langsiktig prosjekt, det er mye som må flyttes. Som sagt så skjer det bare én til to ganger i uka, og jeg syns ikke den stabiliteten er så ille når det går signaler annethvert sekund. Hvis vi sier to ganger i uka, har det kommet inn 150 000 signaler på den tiden.

Aha, det er forklaringen. Vel, jeg har aldri hatt problemer med minnet, og den støtter det jeg trenger. Men takk for tipset!

Hvis jeg kunne fått systemet akkurat som jeg ville med noen av de greiene, ville jeg kastet meg over det med stor glede. Men bare inntak av temperatursensor med klimalogging (temp/fuktighet/lufttrykk) og styring av ovner og Z-Wave-termostater består av noen Pyton-script på rundt 1000 linjer og LUA skripts på kanskje 500 for å få fleksibiliteten jeg vil ha på valg av nattesenkning, endring av temperaturer av brukeren og så videre. Så det er nok ikke så veldig sannsynlig. ?

OK, så en secondary controller, skal det være mulig for den å sende signaler til nettverket? Det er ikke så viktig om den kan ta imot, det viktige er om den kan sende.

Eller andre kontrollere? Jeg har et stort sett vanntett driftssystem: Hvis det ikke kommer MQTT-meldinger fra Z-Wave-nettverket via Hass til hovedsystemet (EventGhost/Girder), har jeg en ekstra Pi med Tellstick Duo som kutter strømmen til den Pi-en der Hass kjører og Z-Sticken er plugget inn og kobler den til igjen etter tre sekunder. Dette blir da i praksis en omstart av Pi-en. Det som irriterer meg, er de to minuttene det tar før Z-Wave er tilgjengelig igjen. Hvis noen i huset da prøver å slå på eller av tv-en eller en av de aktive høyttalerne som er styrt av dette, virker det jo ikke. Jeg skal sette opp en ekstra Pi med rfxTRX for å unngå denne pausen på det som styres av 433 mHz (samme opplegg der, hvis det ikke kommer noe i løpet av 15 sekunder, har noe kjørt seg, så hoved-Pi-en startes om igjen - dette skjernormalt et par ganger i uka), og det ville vært topp hvis jeg kunne ha en ekstra Z-Stick i den også, så av/på-signaler kunne gå til den istedenfor den som holder på å starte om.

De greiene er da altfor primitive. Det skal være fleksibilitet og muligheter i systemet. Men jeg har nå bestilt rfxTRX, jeg tror jeg holder meg til det jeg er kjent med inntil videre.

Jeg måtte ha noe nå, spørsmålet var bare hvor mange jeg skulle kjøpe. Men Arduino Mega koster rundt 500 i Norge, iallfall. Og Kina tar for lang tid.

Jepp, jeg har nettopp bestilt to stykker, så en som jeg trener nå, og en reserve. Men jeg lurte bare på om det var utgående siden to av stedene som har hatt den (Teknikmagasinet og Kjell.com) enten ikke har den lenger eller holder på å selge ut det de har igjen.

Regner med at det vil være på samme måte på Node-RED. Men med Arduino til 500, senderen og mottakeren til en hundrelapp og kanskje en times jobb for å få satt sammen greiene, vil det for meg si at en rfxTRX433e til 900 kroner blir et bedre kjøp for meg.

Aha, sorry. Det så jeg ikke, jeg så under R og H... Det ser ut som snedige greier. Men funker det å koble det til en Pi direkte, eller må jeg feste det til en Arduino Mega og så kjøre den på Pi-en med USB?

Rollertrol? Jeg ser iallfall ikke den (Hasta) på lista. Men jeg må ærlig innrømme at jeg aldri har sett på RFlink. Kanksje verd å gjøre. er det bare å plugge den inn i en Pi, eller er det mer avansert? Den ser ganske "DIY", som det heter på ny-norsk, heller enn "plug and pray".

Jeg ser at det er stadig færre steder de selger den i Gnore nå. Holder den på å gå ut? I så fall må jeg vel kjøpe 5-6 stykker så jeg aldri går tom for dem, siden jeg ikke har tenkt å endre ryggraden i systemet mitt (basert på Tellstick Duo, rfxTRX og Z-Stick) hvis jeg kan unngå det!

Tro meg, hvis "sentralen" min (en Windows server 2016 med virtuell maskin pluss to Pi som alle passer på at alt er i gang og kan kan slå av og på igjen hverandre hvis noe låser seg), så har termostaten på ovnen vært ute ganske lenge. For da har strømmen vært borte mer enn åtte timer, som er den tiden UPS-en min med to 110 Ampere 12 V båtbatterier kan kjøre.

Hvis det er sånn det må foregå, så blir spørsmålet mitt hva som gjør dette bedre enn å sette en Z-Wave-strømplugg (eller til og med 433 mHz-plugg) på ovnen og så vite når den slår seg av og på ved at det er systmet som aktivt gjør det?

Nope. Den selgeren i Kina bløffet tydeligvis. Det han hadde og ville selge, var ikke løse keypads, men bare hele låser av innendørs hotelldørtype.

Hmm... Det er ikke likt hos meg. Bortsett fra Friendly name som Dørlås (som jeg selv har satt), så ser jeg ikke produsentnavn og sånt i dem.

Det slo meg plutselig hvor jeg hadde tenkt feil (mens jeg jobbet med den egentlige jobben min...underbevisstheten kan være rar sånn). Dette funker: - alias: Termostater modus av action: data_template: entity_id: "{{('climate.termostat_'+trigger.payload+'_heating')}}" operation_mode: 'Off' service: climate.set_operation_mode condition: [] id: '152406878952579' trigger: platform: mqtt topic: ZWaveTermostatModusAv

Hvor mye eldre da? Jeg har en i hvitt metall som er 4-5 år gammel (den aller minste typen), og den gjør ikke det.

Jeg har faktisk flere ganger opplevd at automations ikke starter på nytt når jeg gjør det fra inne i Hass, derfor begynte jeg å starte det om igjen fra kommandolinjen. Og App Daemon er litt overkill for det lille jeg gjør. Men jeg kan sende koden bort på Hass-forumet, det er alltid noen der som ser hva som skjer. Takk for hjelpen så langt!

Det måtte jeg, ja! Takk! Det funket med "entity_id": "climate.termostat_8_heating", "operation_mode": "heat" Jeg prøvde å tilpasse koden til automations (jeg må redigere fila "manuelt" via VNC på Pi-en fordi det ellers herper formateringen min med forklaringer og ### som skiller): - alias: Termostater modus av action: data_template: payload_template: {{('entity_id': 'climate.termostat_'+trigger.payload+'_heating'), ('operation_mode': 'off')}} service: climate.set_operation_mode condition: [] id: '152406878952579' trigger: platform: mqtt topic: ZWaveTermostatModusAv Det funket ikke, og det understreket en av de store ankepunktene mine mot programmering i Home Assistant: Hvis noe er feil, virker ingen automations. Hvis et skript har feil i noen av de andre systemene mine, påvirker det ikke andre skripts (jeg vet at skripts og automations er atskilt i Hass, i EG og Girder er det samme greia). Og noen feil, som denne, gjør at Hass ikke kan starte i det hele tatt. Men det er selvagt ikke noe problem hvis man faktisk vet hva man gjør...