Moskus

... men hvorfor skulle det det?

Ja, avhengig av hvilken firmware det er på Z-wave-modulen må du velge riktig plassering. Tidligere firmware begynner kodene på plass 60 og oppover.

Mulig det er noe feil med HeatIt-termostaten? Kunne vært verdt en telefon dem for å sjekke. Jeg hadde en hvor reléet ikke slo seg på. Ellers fungerte termostaten prikkfritt, og den rapporterte at alt fungerte som den skulle. Men temperaturen steg jo aldri. Fikk selvfølgelig ny termostat.

Ja, @lilfire vi skal ikke dele lenker fra det forumet.

... men jeg ser ingen telling, som jeg burde. Etter dette: 07.01.2020 01:00:32:: IObserver OnError: Den eksterne enheten avsluttet WebSocket-tilkoblingen uten å fullføre lukkeprosedyren. 07.01.2020 01:00:33:: IObserver OnCompleted: Live measurement stream has been terminated. Skal det komme noe á la dette: 12:18:27 TibberSeer Warning IObserver OnCompleted: Live measurement stream has been terminated. 12:18:29 TibberSeer Warning RealTime measurements are not running. Waiting 30 seconds before restarting thread... 12:18:39 TibberSeer Warning RealTime measurements are not running. Waiting 20 seconds before restarting thread... 12:18:49 TibberSeer Warning RealTime measurements are not running. Waiting 10 seconds before restarting thread... 12:18:54 TibberSeer Warning RealTime measurements are not running. Waiting 5 seconds before restarting thread... 12:18:59 TibberSeer Warning RestartRealtime triggered... ... hvis du har siste versjon. "Keep Realtime Alive" må være på, men det tror jeg den er som default.

Det burde ikke være umulig å konvertere, men encrypt/decrypt-funksjonene må man også ta høyde for. def encrypt_packet(self, data): padlen = 16 - (len(data) % 16) for i in range(padlen): data = data + chr(padlen) data = data.encode('utf-8') cipher = AES.new(self.key, AES.MODE_CBC, self.iv) encrypted = cipher.encrypt(data) length = len(encrypted) prelude = bytearray([0x10, 0x00, 0x00, 0x00, length]) return prelude + encrypted def decrypt_packet(self, data): cipher = AES.new(self.key, AES.MODE_CBC, self.iv) decrypt = cipher.decrypt(data) padding = decrypt[-1:] decrypt = decrypt[:-ord(padding)] return str(decrypt, 'utf-8') ... men det er sikkert mulig med .NET også.

Ah, sånn ja. Så du styrer Soundbar direkte fra Home Assistant. Da burde det vel være kakestykke å gjøre noe tilsvarende i andre systemer.

Hvilken pluginmodul er det vi snakker om her? Jeg tror @strips er inne på noe, ser ut som en 1000-feil et sted. Hvis vi antar at volt (237 V) og ampere (ca 0,1A) er riktig, blir effekten 23,7 watt.

Men da er det Harmony som gjør jobben? Den takler "cycling input".

25 watt i standby ville i alle tilfeller være altfor mye for en ovn. Det er ikke en vifteovn, vel?

Nei, de skal være rett. Hva får du?

220V->5V for innebygging finnes, men de er ikke gratis. Og de tar plass.

UZB1 kunne restores til før, men ikke med ny firmware. AeoTec Z-stick kan bare tas backup med med AeoTec's egen programvare. For det er praktisk.

Den kan felles inn, men det løser nok ikke noe problem med tilkoblet strøm. Den skal ha 5V, ikke 220V... Innfellingen skjer i vegg, og det er da praktisk med en boks bak. Det er altså noe man egentlig må tenke på når man setter opp veggen, men da blir det riktignok veldig pent.

Ja, selvfølgelig. "Morgen" er kl. 06:20 i ukedagene og kl. 07:15 i helgene (grunnet yngste datter) "Dag" går automatisk på når alarmen blir skrudd på i ukedager (eller når Lux ute går over nivå X og alarmen er på), eller manuelt når alle har kledd seg på fridager. "Kveld" blir det når jentenes "sovelys" (som også styrer rullegardinen) blir skrudd på etter kl. 18:30. "Natt" blir det enten manuelt, eller når det ikke har vært bevegelse i løpet av den siste timen i huset etter kl. 22:00 (og TV og/eller forsterker er av). "Natt" har jeg tenkt å få automatisert med en sengesensor, enten en bedre trykkmatte enn det jeg har eller vektceller på beina. Det kan også brukes som trigger for "Morgen". Hvis en person har reist seg fra senga etter kl. 05:30 er det morgen. Jeg har hatt stort hell med AeoTec Multisensor 6. De rapporterer raskt (hos meg) og jeg har dem tilkoblet fast strøm. Dermed blir de en aktiv del av nettverket, og kan sende data oftere uten at noe batteri tappes. Hvilket intervall snakker vi om her?

Luftlinje. Uten vegger (gips, isolasjon etc)? Det er ikke veldig sprekt nei.

Hva er distansen mellom den og kodepanelet?

(Hvordan la du den inn i deConz?)

Ja, hadde det vært så enkelt så hadde det selvfølgelig blitt gjort. Men det festlige med async-hendelser er at det ikke er bent frem å håndtere. Jeg bruker Tibber sin eget .NET SDK, og det er ikke håndtert der, så jeg har begrenset mulighet til å overstyre det. Ja. "Restart realtime" er en kommando som du kan trigge med hvilket som helst Event som man pleier. Hvis du har EasyTrigger kan du sjekke om en av child-devicene ikke har oppdatert seg på X sekunder, og restarte deretter. Jeg er bare overrasket over at det fremdeles er et problem. En debug logging til fil hadde vært hendig...

Du kan starte valgt effekt fra app'en (som er det som heter "movie"), du kan kjøre en demo (dvs "effect"), du kan pause ("RT") og skru den av.

... google? https://www.instructables.com/id/External-Antenna-for-ESP8266/

Bare vær OBS på at de ikke passer inn i Elko-rammer. ... men hvilken er det du har? Vanligvis skal ikke kontrollere på batteri behøves å vekkes før de reagerer.

Ah, det forklarer saken.

Men hvordan fungerer denne, da? Er den ikke assosiert til et relé eller noe slikt i nærheten? Dekning burde jo da ikke være noe problem, også den krypterte kommunikasjonen kan jo gjøre noen hopp.

Lokal tilgang burde være viktigere enn alle apper og skyløsninger. Men det vitale er etter min mening en god og veldokumentert API og bør være øverst på prioriteringslisten. APIen kan gå via skyen hvis det ikke er noen andre måter å få det til på, men lokal tilgang er selvfølgelig å foretrekke. Noe av grunnen til at jeg bruker Tibber er nettopp dette. Det går riktignok via skyen (der burde f.eks. sanntidsdata kunne hentes direkte), men APIen er så bra å bruke slik at "alle" kan lage integrasjoner mot større smarthus-systemer. Å ha en egen hub er i prinsippet ikke et problem etter min mening. Å kunne kommunisere med nevnte hub er viktigere enn å unngå en hub. F.eks. kan hub'en da ha tilgang til kablet nett (som er å foretrekke) og så får hub'en ta seg av kommunikasjonen med "nodene". Aller helst burde man unngå slike hub'er, og heller bruke en allerede eksisterende protokoll. Z-wave er å foretrekke (det er enklere for sluttbruker, mindre spørsmål med det), Zigbee hvis man må. Z-wave først, etter min mening. Det øker sjansen for kompabilitet. Er det Z-wave verifisert, så skal det fungere. Det som er synd med Zigbee er at det mangler en del i software-laget, og det er opp til produsenten selv å definere dette. Dermed kan det fungere på tverrs av hub'er, men det trenger ikke det. Z-wave er jo også i ferd med å bli åpnet opp, og det vil forhåpentligvis gi nye og spennende muligheter samtidig som det forhåpentligvis blir billigere å produsere. Kun nødvendig hvis wifi/nettverk. Igjen kun nødvendig hvis wifi/nettverk. Ja, enig. En selvfølge.