POPP Outdoor Siren (POPE005107)

[krikan]

Hallo Reiner!
Das ging schnell. 

Ergebnis nach meiner derzeitigen Interpretation in (Halb)klartext (work in progress):

Code Auswählen Erweitern

manufId 0115 fwId 0101 fwChecksum b522 upgradable 01 nrTargets 00 maxFragmentSize 001e fwId1 0000
manufId ist die von zwave.me und nicht von Popp analog zu den Popp Rauchmeldern.

Du hast noch kein Firmwareupdate auf http://ota.zwave.eu/OTA/POPE005107/POPE005107_BOOT_V1.3_FOR_OTA_15_12_2015.bin gemacht. Korrekt?
Wenn Du "get <device> version" abrufst, ist dann App = 1.01?

Ansonsten muss ich noch weiter suchen/basteln..

Gruß, Christian

[gamauf]

Hallo Christian!

Wenn Du das FW-Update hin bekommst profetiere ich ja auch davon; ist also in meinem eigenen Interesse Dir zu helfen!


Ich glaube Popp läßt alles bei zwave.me entwickeln...

Richtig, ich habe das Update NICHT installiert.
Nein, App = 1.1

Code Auswählen Erweitern

version Lib 3 Prot 4.5 App 1.1 HW 1 FWCounter 0

Viel Erfolg!

LG
Rainer

[krikan]

Wenn Du das FW-Update hin bekommst profetiere ich ja auch davon; ist also in meinem eigenen Interesse Dir zu helfen!

Langsam an  Ist bisher ein steiniger Weg wegen wenig Infos und insbesondere Beispiele. V2 der Class klappt zumindest mit AEOTEC Multisensor schon, aber mir fehlen noch viele Details und V3 für die Popp Sirene und meine Popp Rauchmelder ist derzeit für mich noch ein Riesenfragezeichen mit eingebauter Elektroschrottproduktionsgefahr..

Ich glaube Popp läßt alles bei zwave.me entwickeln...

Ja, das sieht so aus.

Nein, App = 1.1

Code Auswählen Erweitern

version Lib 3 Prot 4.5 App 1.1 HW 1 FWCounter 0

Ja, sieht in der Anzeige momentan wie .1 aus, Raw-Wert ist aber 01hex. Das interpretiere ich als .01 also 1.01 und habe für mich 10_Zwave.pm so umgebaut.
Dabei sind sich die Hersteller aber auch nicht einig:  07hex ist bei Fibaro .7 und bei Aeotec .07

Gruß, Christian

[krikan]

Ja, sieht in der Anzeige momentan wie .1 aus, Raw-Wert ist aber 01hex. Das interpretiere ich als .01 also 1.01 und habe für mich 10_Zwave.pm so umgebaut.
Dabei sind sich die Hersteller aber auch nicht einig:  07hex ist bei Fibaro .7 und bei Aeotec .07

Vielleicht könntest Du mir doch das Log mit verbose 5 der "get <device> version" - Abfrage mit der Antwort posten. Nicht, dass es doch 1.1 ist und ich etwas übersehe.

[krikan]

Hallo Rainer,
Sigma Designs hat für den Raspberry eine vorkonfigurierte Z-Ware Installation unter http://z-wave.sigmadesigns.com/design-z-wave/z-wave-public-specification/ (Seite ganz untern) veröffentlicht, die auch FIRMWARE_UPDATE_MD bis zur Version 3 unterstützt. Vielleicht hilft Dir das für das Sirenen-Update.
Ob und wann ich bei der Class weiterarbeite habe ich angesichts der Veröffentlichung der Specs und der Z-Ware noch nicht entschieden.
Gruß, Christian

[gamauf]

Hallo Christian!
Freut mich, daß Du an mich gedacht hast. Danke!

Vielleicht probier ich's, wenn ich mal viel Zeit übrig hab, aus, aber da ich mit dem UserReading einen funktionierenden Workarround für das einzige Problem das dezeit in der neuen FW gefixt ist habe ist die Priorität für mich da derzeit eher gering...
aber so straight forward dürfte das mit dem Raspberry image auch nicht klappen wie man hier lesen kann:
https://forum.fhem.de/index.php/topic,57300.msg488275.html#msg488275

Kann es sein das ich Dir hier noch eine Antwort schulde?:

Vielleicht könntest Du mir doch das Log mit verbose 5 der "get <device> version" - Abfrage mit der Antwort posten. Nicht, dass es doch 1.1 ist und ich etwas übersehe.

Hab das womöglich in der Ferienzeit übersehen!

Grüße
Rainer

[A.Harrenberg]

Hi,

aber so straight forward dürfte das mit dem Raspberry image auch nicht klappen wie man hier lesen kann:
https://forum.fhem.de/index.php/topic,57300.msg488275.html#msg488275

na ja, ich habe auch nicht wirklich VIEL Energie reingsteckt um die Dokus zu lesen ,-)

Aber ja, ZWave-Stick reinstecken und booten reicht anscheinend schon mal nicht aus um das was rauszukitzeln.

Gruß,
Andreas.

[gamauf]

Aber ja, ZWave-Stick reinstecken und booten reicht anscheinend schon mal nicht aus um das was rauszukitzeln.

genau das hab ich gemeint ... ohne viel Energie rein zu stecken schnell mal ein FW-Update einspielen... wird nicht funktionieren.
und die viele Energie ist bei mir derzeit wo anders besser aufgehoben...

Grüße
Rainer

[A.Harrenberg]

Hi,

genau das hab ich gemeint ... ohne viel Energie rein zu stecken schnell mal ein FW-Update einspielen... wird nicht funktionieren.

selbst wenn das System "läuft" kommst Du erst mal nicht weiter, Du brauchst ja ein Updatefile das vom Aufbau her zu dem System "passt". Und ich würde mich nicht darauf verlassen das solche Files immer nur die reinen Binärdaten enthalten und nicht vielleicht auch irgendwelche Zusatzinfos die der Update des jeweiligen Herstellers dann auswertet und "ausfiltert".

Gruß,
Andreas.

[refi]

Hallo!

Das von Reiner beschrieben Problem (Antwort #53; hängt sich auf) tritt auch bei meiner Sirene (Lib 3 Prot 4.5 App 1.3 HW 1 FWCounter 0) auf.

Der Popp-Support (Antwort von heute) verweist nun auf eine aktuelle Firmware 1.4 (http://ota.zwave.eu/).

Das Firmware-Update soll über Z-Way laufen:
http://manuals-backend.z-wave.info/make.php?lang=de&sku=pope005107&type=popp

Hat damit schon jemand Erfahrungen gesammelt?

Außerdem kam die Aussage:  "...bei der Sirene handelt es sich um ein Flirs Gerät. Dieses darf nicht vom Controller gepollt werden. Dies kann zu Ihrem beschriebenen Fehlerbild passen....".

Ich habe mein nächtliches "get battery" jetzt deaktiviert, obwohl die "Aufhänger" nicht zeitgleich oder direkt nach dieser Abfrage auftreten.

Kann ich noch etwas tun?

Nachtrag:
Das Problem existiert seit Firmware 1.1 (hier im Beitrag; ich habe 1.3; aktuellste ist 1.4). Der Popp-Hub ist auch nur ein Raspberry. Ich kann mir schwer vorstellen, dass dieses Problem seit Firmware 1.1 auftritt und nicht in 1.2 und 1.3 behoben wurde. Also muss der Popp-Hub "etwas anders" machen – oder er zeigt den Sirenen-Ausfall einfach nicht an und keiner merkt es, bis es wieder von selber zum Laufen kommt.


Gruß
René

[krikan]

Hallo Rene!

"...bei der Sirene handelt es sich um ein Flirs Gerät. Dieses darf nicht vom Controller gepollt werden. Dies kann zu Ihrem beschriebenen Fehlerbild passen....".

Ein mal pro Tag "get battery" würde ich persönlich nicht als Pollen einordnen. Darf man dann bei der Sirene gar keine Befehle verschicken oder nur im Monatsrhytmus? Das ist eine ersnstgemeinte Frage  .
Meine Popp FLIRS-Rauchmelder (modelId ist aufgrund einer (immer noch unbehobenen?) Firmwareschwäche gleich der Popp Sirene) hängen sich nicht auf, auch wenn ich sie gelegentlich mit Abfragen quäle.

Also muss der Popp-Hub "etwas anders" machen

Hast Du das selbst festgestellt? Falls ja, dann kannst Du evtl. ein Log vom Hub liefern.

Gruß, Christian

[refi]

Hallo Christian,

ich habe keinen Popp-Hub zum Vergleich. War nur eine Vermutung, weshalb das Problem bei Popp nicht bekannt ist. Ich habe dem Popp-Support geschildert, dass ich die Sirene 1x/Tag abfrage und wurde aufgefordert, diese Abfrage nicht durchzuführen. Das habe ich nun gemacht, obwohl es, wie Du schreibst, wenige logisch klingt.
Der Support betrachtet auch ein Temperaturproblem durch Sonneneinstrahlung als kritisch - sehr gut bei einem Solargerät . Aber das kommt bei mir nicht in Frage. Die Ausfälle treten auch bei kalten Temperaturen und wenig Sonne auf. Ich habe einen Umweltsensor im Einsatz und konnte anhand der Temperatur und Helligkeitswerte kein Schema für die Ausfälle erkennen.
Ich frage den transmit-readings-Wert ab und schicke mir eine Email, wenn ein NO_ACK kommt.

Aber wie wird das NO_ACK eigentlich festgestellt, wenn die Sirene nicht gepollt wird, was sie ja nach Aussage Support (auch in der Doku siehe Link explizit aufgeführt) nicht darf?

Gruß
René

[krikan]

Aber wie wird das NO_ACK eigentlich festgestellt, wenn die Sirene nicht gepollt wird, was sie ja nach Aussage Support (auch in der Doku siehe Link explizit aufgeführt) nicht darf?

NO_ACK kann nur bei Kommunikation zwischen FHEM und Gerät entstehen. Von alleine stößt FHEM mWn keine Kommunikation mit der Sirene an. Das muss grds. durch den User eingerichtet sein. Bei Dir bspw. das "get battery". Wenn NO_ACK für Sirene nach Entfernen von "get battery" immer noch kommt, dann bitte verbose 5 und einmal Log zeigen.

Vorteil von Popp Hub: Softwareentwicklung für Hub und Firmwareentwicklung von Sirene erfolgen afaik vom gleichen Hersteller zwave.me, der die komplette Doku kennt.

[scooty]

Hallo,
als kurze Info zu dem Thema:
Ich war auch in Kontakt mit dem Support wegen der oben von Reiner beschriebenen Probleme (Antwort #53).

Habe jetzt mit Hilfe eines Popp Hubs ein Firmware Update der Sirene von 1.1 auf 1.4 durchgeführt.
Da es allerdings Probleme bei Verwendung der oben verlinkten FW-Dateien gab (keine Reaktion der Sirene nach Abschicken des FW-Updates), habe ich eine (spezielle?) 1.4 Firmware Datei vom Support zugesendet bekommen, die ich hier 'mal anhänge (Erlaubnis vom Popp Support liegt vor).
Damit hat das Update geklappt.

Ob damit jedoch alle Probleme behoben sind, kann ich noch nicht sagen, habe die Sirene noch nicht wieder im "Produktionsbetrieb".
Melde mich dann noch mit weiteren Erfahrungen.

Andreas

Edit:
Noch eine Eigenart, die ich im Laufe meiner Beschäftigung mit dem Gerät herausgefunden habe:
Die Temperaturreports werden von der Sirene nur gesendet, wenn sie auf dem Halter montiert ist!

[gamauf]

Was soll der Blödsinn mit "man darf die Sirene nicht pollen"?!
Das ist ja wie mit Schrödingers Katze: schau ja nicht in die Kiste, sonst ist die Katze drinnen tot! Aber solange du nicht hineinschaust weißt du nicht ob sie noch lebt...!
Man merkt dann erst, wenn sie bei einem Einbruch nicht losgeht, dass sie wieder hängt! Guter Vorschlag!!!

Gut zu wissen, dass es eine neue FW gibt, die mehr als nur das Problem mit der negativen Temperatur fixt!

Bin gespannt auf Andreas' (scootys) feedback ob die neue FW hilft. Falls ja, muß ich mir dann eine Möglickkeit suchen die neue FW auf meine Sirenen zu bekommen...

LG
Rainer