xibriz Skrevet 17. januar 2017 Skrevet 17. januar 2017 Jeg har ett Logical Rule (event) som er som følger: Når Z-Wave enhet A slår ser på: Slå på Z-Wave enhet B, C, D osv. Problemet er hvis f.eks. enhet C allerede er på, så slår den seg av. Og omvendt. Som en slags "toggle" selv om det ikke er definert i eventet. Alle enhetene er assosiert opp mot ZWC-K8. Kan denne lage trøbbel på noe vis? Siter
xibriz Skrevet 17. januar 2017 Forfatter Skrevet 17. januar 2017 (endret) Dette er det jeg vet ut fra loggen: Enhet X trigger enhet A Enhet A slår seg på og rapporterer at den er på (Dette trigger event om at alt skal på) Ett sekund senere rapporterer enhet A at den er av (Dette trigger event om at alt skal av) Litt mer enn ett minutt etterpå raooirterer enhet A at den er på igjen (Dette trigger event om at alt skal på) Etter dette kan enheter ha tilfeldig status Hvordan kan man best finne ut av hvorfor enhet A er ustabil? Eller om det er noe annet som trigger den? (det er en z-uno) Endret 17. januar 2017 av xibriz Siter
xibriz Skrevet 17. januar 2017 Forfatter Skrevet 17. januar 2017 (endret) Jeg tror jeg har funnet problemet i loggen, kanskje noen kan hjelpe meg å skjønne dette. Jeg er usikker på om det er z-way relatert eller relatert til z-wave-protokollen. I loggen under så ser man i den første bolken at device 13 rapporterer level = False (Off) Dette trigger at device 12 skal få status ON Men så, noen millisekunder senere kommer en ny, men samme melding fra device 13 Og av en eller annen ukjent årsak trigger dette at device 12 skal få status OFF Hmm.... ? Sitat ... [2017-01-17 05:37:07.113] [D] [zway] RECEIVED: ( 01 09 00 04 00 0D 03 25 03 00 DA ) [2017-01-17 05:37:07.113] [D] [zway] SENT ACK [2017-01-17 05:37:07.113] [D] [zway] SETDATA controller.data.incomingPacket.nodeId = 13 (0x0000000d) [2017-01-17 05:37:07.114] [D] [zway] SETDATA controller.data.incomingPacket.frameType = "singlecast" [2017-01-17 05:37:07.114] [D] [zway] SETDATA controller.data.incomingPacket = ********** [2017-01-17 05:37:07.114] [D] [zway] SETDATA devices.13.data.lastReceived = 0 (0x00000000)[2017-01-17 05:37:07.114] [D] [zway] SETDATA devices.13.instances.0.commandClasses.37.data.level = False [2017-01-17 05:37:07.128] [core] Notification: device-info (device-OnOff): {"dev":"Verisure Bridge Fibaro","l":"off"}[2017-01-17 05:37:07.135] [core] --- ZWayVDev_zway_12-1-37 performCommand processing: {"0":"on"} ... [2017-01-17 05:37:07.591] [D] [zway] RECEIVED: ( 01 09 00 04 00 0D 03 25 03 00 DA ) [2017-01-17 05:37:07.591] [D] [zway] SENT ACK [2017-01-17 05:37:07.591] [D] [zway] SETDATA controller.data.incomingPacket.nodeId = 13 (0x0000000d) [2017-01-17 05:37:07.591] [D] [zway] SETDATA controller.data.incomingPacket.frameType = "singlecast" [2017-01-17 05:37:07.591] [D] [zway] SETDATA controller.data.incomingPacket = ********** [2017-01-17 05:37:07.592] [D] [zway] SETDATA devices.13.data.lastReceived = 0 (0x00000000)[2017-01-17 05:37:07.592] [D] [zway] SETDATA devices.13.instances.0.commandClasses.37.data.level = False [2017-01-17 05:37:07.602] [core] --- ZWayVDev_zway_12-1-37 performCommand processing: {"0":"off"}... Endret 17. januar 2017 av xibriz Siter
xibriz Skrevet 17. januar 2017 Forfatter Skrevet 17. januar 2017 Det er visst flere som opplever problemer med nyeste versjon av "if > then" i z-way. Bytter til "Logical rule" for å se om det løser problemet. Btw. Noen av dere HS-gutta må migrere over hit ? Siter
Moskus Skrevet 18. januar 2017 Skrevet 18. januar 2017 14 timer siden, xibriz skrev: Btw. Noen av dere HS-gutta må migrere over hit Det er sjeldent man nedgraderer frivillig. Men når bare @iblis våkner fra vinterdvalen(?) sin så kommer han nok. Siter
iblis Skrevet 18. januar 2017 Skrevet 18. januar 2017 Dessverre så bruker jeg openHAB som regelmotor og har 0 erfaring med å bruke Z-Way på denne måte. Jeg vet at i de siste versjonene av Z-Way har det kommet en default app som auto slår av tamper/alarm sensorer etter en viss tid for enheter som ikke støtter dette automatisk. Det kan ikke være at du har denne aktivert og at den behandler devices.13.instances.0.commandClasses.37.data.level som en tamper sensor og slår den av automatisk som igjen krøller til if/then/else regelen din? 2 timer siden, Moskus skrev: Men når bare @iblis våkner fra vinterdvalen(?) sin så kommer han nok. Ja, nå er det på tide jeg kommer meg ut av vinterdepresjonen. ? Huff.. så mye innhold å gå igjennom. Men bra å se at aktiviteten har vært stor den siste måneden ? Siter
xibriz Skrevet 18. januar 2017 Forfatter Skrevet 18. januar 2017 3 minutter siden, iblis skrev: Jeg vet at i de siste versjonene av Z-Way har det kommet en default app som auto slår av tamper/alarm sensorer etter en viss tid for enheter som ikke støtter dette automatisk. Det kan ikke være at du har denne aktivert og at den behandler devices.13.instances.0.commandClasses.37.data.level som en tamper sensor og slår den av automatisk som igjen krøller til if/then/else regelen din? Appen "Tamper Auto Off" er ikke default i min installasjon (v2.2.5). Men etter å sjekket loggene er jeg ganske sikker på at appen "If -> Then" har noen bugs fordi alt fungerer som forventet med appen "Logical Rule". 1 Siter
Anbefalte innlegg
Bli med i samtalen
Du kan publisere innhold nå og registrere deg senere. Hvis du har en konto, logg inn nå for å poste med kontoen din.