POPP Outdoor Siren (POPE005107)

Begonnen von Lars, 22 Oktober 2015, 15:05:58

Vorheriges Thema - Nächstes Thema

refi

Ich musste gestern auf die Leiter und habe die Sirene aus/eingeschaltet, da sie seit 3 Tage nicht mehr geantwortet hat und auch nicht von selbst "zurück gekommen" ist. Die Blitz-LEDs haben geglimmt, ein Pfeifen war diesmal nicht zu hören. Sofort danach ein "get battery" → 100%.

Mit verbose 5 kamen bei mir anschließend bei einem einfachen "off" Fehlermeldungen:

no stored commands in Internal secMsg found
Error, nonce reveived but no stored command for encryption found
Error, no send_nonce to decrypt message available

Der Befehl wurde aber ausgeführt.

Ich habe dann, um Fehlalarm beim Testen zu vermeiden, ein "set Aussensirene configSwitchMode FlashOnly" eingetragen – danach waren diese Fehlermeldungen weg????

Nur eine blöde Idee: Vielleicht muss regelmäßig ein "set-Befehl" abgesetzt werden, damit die Sirene in einem "stabilen Zustand" ist... (werde ich testen)

@Andreas (scooty): Wie hast Du das Update durchgeführt? Kannst Du bitte eine kurze Anleitung zusammenschreiben. Wenn ich irgendwann wieder auf die Leiter muss, möchte ich gleich updaten. Danke!

Gruß
René
Raspberry Pi3: Duofern, Z-Wave, EnOcean

A.Harrenberg

Hi,
Zitat von: refi am 09 Dezember 2016, 08:05:32
Mit verbose 5 kamen bei mir anschließend bei einem einfachen "off" Fehlermeldungen:

no stored commands in Internal secMsg found
Error, nonce reveived but no stored command for encryption found
Error, no send_nonce to decrypt message available
das sind typische Fehlermeldungen wenn während der Kommunikation mit Security was schief gelaufen ist und zwischendurch ein Paket verlorengegangen ist. Der Ablauf kommt dann leider durcheinander und es können dabei leider auch Befehle auf dem Security-Sendstack liegen bleiben was dann dazu führt das die ganze Kommunikation ab dann nicht mehr in Ordnung ist ,-(

Wenn Du mal ein Listing des Gerätes machst solltest Du mal schauen ob es im Listing einen Abschnitt mit "secMsg" gibt der noch Befehle enthält. Falls ja hilft momentan leider nur ein Neustart von fhem...

Zitat von: refi am 09 Dezember 2016, 08:05:32
Der Befehl wurde aber ausgeführt.

Ich habe dann, um Fehlalarm beim Testen zu vermeiden, ein "set Aussensirene configSwitchMode FlashOnly" eingetragen – danach waren diese Fehlermeldungen weg????
Ich vermute das DIESER Befehl NICHT ausgeführt wurde sondern ein "älterer" der noch in dem security-Stack lag... Das wäre eine typische Fehlersituation wenn die Kommunikation durcheinander gekommen ist. Es bleiben Befehle auf dem Stack liegen und bei der nächsten Runde wird der alte Befehl ausgeführt und der neue bleibt dann wieder auf dem Stack liegen ,-(

Ein Update das die Robustheit der Kommunikation erhöht wird gerade noch ein wenig getestet und ich werde es voraussichtlich in den nächsten Tagen bei Rudi abgeben damit er es einbaut.

Zitat von: refi am 09 Dezember 2016, 08:05:32
Nur eine blöde Idee: Vielleicht muss regelmäßig ein "set-Befehl" abgesetzt werden, damit die Sirene in einem "stabilen Zustand" ist... (werde ich testen)
Theoretisch möglich, ich halte es aber für nicht sehr wahrscheinlich.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

krikan

Tauchen die Probleme mit dem "Absturz" der Sirene eigentlich nur bei Einbindung über SECURITY auf? Hat das schon mal jemand getestet?

A.Harrenberg

Hi,

war es nicht so das die Sirene ohne SECURITY keine Funktionen bereitstellt und daher immer mit SECURITY betrieben werden muss?

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

krikan

Keine Ahnung. Laut Handbuch würde ich tippen es geht auch ohne:
ZitatThe secure communication is activated on default during inclusion unless explicitly suppressed.

refi

#80
Hallo,

ich habe nochmal die Logs nach allen "Aufhängern" seit April 2016 durchforstet. Auffällig ist, dass die letzte Meldung vor einem Ausfall folgende ist:

secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd

Direkt danach kam jeweils ein NO_ACK von der Sirene.

Zu diesen Zeitpunkten gab es keine Kommunikation zur Sirene, welche durch Aktionen von mir initiiert wurden. Ob die Sirene zu diesem Zeitpunkt versucht hat, ein Temperaturupdate zu senden, kann ich nicht nachvollziehen.

Andreas (Harrenberg) hat in einem anderen Beitrag diese Meldung erklärt (secStart wenn Security-Kommunikation beginnt, danach sollte ein secEnd kommen - wenn secEnd nicht kommt = diese Fehlermeldung).

Ein Betrieb der Sirene ohne Security habe ich bisher nicht versucht.

Weil ich keine Lust habe, ständig auf die Leiter zu steigen, versuche ich jetzt eher unlogische Aktionen:

jede Nacht läuft jetzt ein "set configSwitchMode FlashSirenDefault"

Hoffnung: durch eine Konfigänderung werden alle Register/Queues auf default gesetzt/zurückgesetzt

Ich berichte, wenn der Fehler wieder auftritt.

Gruß
René
Raspberry Pi3: Duofern, Z-Wave, EnOcean

A.Harrenberg

Hi
Zitat von: refi am 10 Dezember 2016, 14:58:10
ich habe nochmal die Logs nach allen "Aufghängern" seit April 2016 durchforstet. Auffällig ist, dass die letzte Meldung vor einem Ausfall folgende ist:

secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd

Direkt danach kam ein NO_ACK.

Zu diesen Zeitpunkten gab es keine Kommunikation zur Sirene, welche durch Aktionen von mir initiiert wurden. Ob die Sirene zu diesem Zeitpunkt versucht hat ein Temperaturupdate zu senden, kann ich nicht nachvollziehen.
Die Meldung sagt im Grunde das für mehr als 6 sekunden auf eine Antwort auf eine secure-Nachricht gewartet wurde ohne das eine gekommen wäre... Das NO_ACK im Anschluss bestätigt ja auch das es dort Kommunikationsproleme gibt.

Falls Dein Log für das Gerät mit verbose 5 läuft könntest Du mal einen Abschnitt daraus posten, dann schaue ich rein. Wenn Du kein "at" oder notify auf das WakeUp hast, dann wird die Sirene wohl versucht haben was zu schicken. Dazu fragt die Sirene nach einer NONCE und das Verschicken (oder das versuchte senden) dieser Nonce startet dann über secStart den Timer der dann hier nach 6 sekunden aufgibt.

Hier können verschiedene Ursachen möglich sein:
- das Gerät antwortet einfach nicht
- der Befehl wurde gar nicht verschickt weil z.B. der Dongle hängt
- ...

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

refi

Zitat von: A.Harrenberg am 10 Dezember 2016, 16:01:55
Falls Dein Log für das Gerät mit verbose 5 läuft könntest Du mal einen Abschnitt daraus posten

verbose 5 läuft erst seit meiner letzten "Leiterbesteigung" - ich melde mich, wenn wieder ein Aufhänger kommt

at oder notify lief nicht zu den Ausfallzeiten nur doif auf reading transmit: NO_ACK


Gruß
René
Raspberry Pi3: Duofern, Z-Wave, EnOcean

umtauscher

#83
Hallo Leute,

ich habe diese Sirene am 26.11.2016 erworben und habe sie seit ca einem Monat montiert.
Gestern morgen hatte ich das gleiche Problem wie hier beschrieben.
Keine Reaktion
Keine Temperaturupdates
LEDs glimmen
Keine Reaktion auf Tamper Sensor.

Allerding betreibe ich kein fhem sondern benutze Indigo auf eine Mac Server.
Da das Fehlerbild exakt identisch ist, wollte ich Euch nur wissen lassen, dass es wohl kein fhem Problem ist.
Allerdings seid Ihr die Einzigen, denen ich zutraue die Ursache zu finden.

Meine Sirene hat übrigens Firmware 1.03. Gibt es Erkenntnisse, dass 1.04 an dem Fehlerbild irgendwas verbessert und hat jemand dieses Update schon gemacht und wie?

Ich denke eingentlich, das Popp den Fehler beseitigen sollte, glaube aber nicht daran, dass man es dort schafft.
Euch allen ein Frohes neues Jahr.

Umtauscher

gamauf

ja, laut Martin Sutton, Popp Support, passiert das, wenn der Z-Wave Chip in der Sirene durch Sonneneinstrahlung auf über 80°C aufgeheizt wird!

Ich schließe daraus, dass Du nicht in Europa sondern (viel) weiter südlicher daheim bist, da solche Temperaturen hier Ende Dezember / Anfang Jänner wohl eher nicht vorkommen! ;)

Wünsche ebenfalls ein gutes neues Jahr!!!

refi

....nicht zu vergessen: Solargerät nicht in die Sonne hängen, sondern nur wohltemperierter Halbschatten – zur Not mehrfach täglich mit Sonnenwanderung umhängen. Mehrere Halterungen gibt es als Sonderausstattung (vermute ich)  ;) ...

Seitdem ich täglich ein "set configSwitchMode FlashSirenDefault" mache, habe ich (seit 10.12.16) keine Ausfälle. Die Hoffnung stirbt zuletzt...

Gruß
René
Raspberry Pi3: Duofern, Z-Wave, EnOcean

umtauscher

Hallo Jungs, erstam danke für Eure erhellenden Antworten. ;-)

Ich finde die "Ursachenanalyse" bzw. "Lösungsvorschläge" von Popp auch lächerlich.
Natürlich ist das Gerät bei mir erst nach dem Ablauf der Rückgabefrist das erste Mal ausgestiegen. (Bei ca -5 °C)
Eine Reparatur scheidet ja bei dem Fehlerbild aus, deshalb die vorsichtige Frage, ob die 1.04 irgend etwas diesbezüglich bringt.

gamauf

Hallo!

scooty scheint hier bisher der einzige zu sein, der ein FW Update durchgeführt hat (siehe Post #73).
Vielleicht kann er uns berichten?
Mindestens drei andere User wären dankbar!

LG
Rainer

scooty

Na, dann 'mal schauen, ob ich etwas zur "Entspannung" beitragen kann.
;)
Seit 2 Wochen ist die Sirene nun mit der 1.04 FW wieder im Outdoor-Einsatz und ist bisher (noch?) nicht wieder ausgestiegen.
Minusgraden von -5°C hat sie bisher standgehalten, befestigt ist sie an der Ostseite des Hauses (also derzeit keine direkte Sonneneinstrahlung).

Habe die Sirene allerdings erst einmal so konfiguriert, dass sie mir keine Temperaturmeldungen sendet (warum? Ich will sie einfach "in Ruhe lassen" und habe genügend andere Sendsoren für Temperaturwerte).
Täglich (besser gesagt "nächtlich") wird der Batteriestand einmal abgefragt, nur einmal ging sie bisher in den Status "transmit NotOK", hat sich aber nach einem erneuten manuellen Versuch am Tage wieder berappelt und brav den Batteriestand gemeldet.

Bin also vorsichtig optimistisch,

Andreas
Fhem auf Gigabyte Brix
CUL V3 HM / CUL V3 MAX / MaxCube aFW Homematic&MAX / ZWave.me ZME_UZB1 / SDuino 433 / Velux KLF200
Homematic / MAX / Logitech Hub / ZWave / Wifi LED / div. 433 Temperatursensoren / pywws WH1080 / IO Homecontrol

umtauscher

Danke, dann muss ich es jetzt nur noch schaffen, die Firmware in das Ding zu bekommen....