POPP Outdoor Siren (POPE005107)

[A.Harrenberg]

Hi,

Das Thema CC FIRMWARE_UPDATE: Ich persönlich werde dort -wie oben erwähnt- nicht dran basteln. Das ist mMn insgesamt eine undankbare Aufgabe die CC in FHEM einzubauen, wenn man kein Testgerät hat. Die CC verschickt Unmengen an Telegrammen. Zudem geht der Bedarf gegen 1 Person. Es gibt mWn nur die Sirene für die überhaupt ein verfügbares Firmwareupdate existiert. Vielleicht hat jemand anderes Spass daran, aber ich wollte Dir zumindest das Problem aufschreiben.

ich hatte mal angefangen mir das anzuschauen aber mangels eines verfügbaren Update-Files erst mal nicht weiter verfolgt. Problem ist das z.B. AEOTEC das Updatefile nicht so freigibt, die wollen ein NDA haben und das File soll anscheinend in die Applikation integriert/eincompiliert werden, damit es nicht so "offen" rumliegt. Das ist bei einem Open-Source Perl Projekt schon mal nicht so ohne weiteres machbar... Daher habe ich das erst mal wieder liegen lassen, vor allem da ja noch einige Sachen in Security und dem ZWCul offen sind.

Die Implementation wäre vermutlich gar nicht soooo schwierig/aufwändig, aber der Nutzen liegt nur ganz knapp im messbaren Bereich...

Gruß,
Andreas.

[gamauf]

Hallo Christian!
Danke für die Infos

Wenn das denn wirklich Dein ZWave-Problem löst/ist.

Das aktuelle Problem halte ich eher nicht für ein Funkreichweitenproblem. Aber die erwähnet zweite Sirene, die ich noch nicht montiert habe, soll an einem Platz der derzeit außerhalb der Funkreichweite des ZWave-Dongels liegt. Da würde mir diese Innensirene als Repeater durchaus helfen!

So nach fünf Tagen hat sich das Teil jetzt wieder aufgehängt!
Hier das Log:

Code Auswählen Erweitern

2016.04.03 11:40:59 4: ZWDongle_Read ZWDongle_0: rcvd 00040012029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.04.03 11:40:59 5: SW: 06
2016.04.03 11:40:59 5: ZWDongle_0 dispatch 00040012029840
2016.04.03 11:40:59 4: CMD:APPLICATION_COMMAND_HANDLER ID:12 ARG:029840 CB:00
2016.04.03 11:40:59 5: ZWDongle_Write 0013120a988059d9cb48fef1b3cb2576 (cb838b79)
2016.04.03 11:40:59 5: SW: 01110013120a988059d9cb48fef1b3cb2576da
2016.04.03 11:40:59 5: ACK received, WaitForAck=>2 for 01110013120a988059d9cb48fef1b3cb2576da
2016.04.03 11:40:59 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.04.03 11:40:59 5: SW: 06
2016.04.03 11:40:59 5: ZWDongle_0 dispatch 011301
2016.04.03 11:40:59 4: ZWDongle_Read ZWDongle_0: rcvd 001376000003 (request ZW_SEND_DATA), sending ACK
2016.04.03 11:40:59 5: SW: 06
2016.04.03 11:40:59 5: device ack reveived, removing 01110013120a988059d9cb48fef1b3cb2576da from dongle sendstack
2016.04.03 11:40:59 5: ZWDongle_0 dispatch 001376000003
2016.04.03 11:40:59 4: CMD:ZW_SEND_DATA ID:00 ARG:0003 CB:76
2016.04.03 11:40:59 4: ZWDongle_0 transmit OK for CB 76, target ZW_Sirene_A2
2016.04.03 11:40:59 4: ZWDongle_Read ZWDongle_0: rcvd 000400121a9881b7b6bf8b944a12d26d1885617fe33059fe688d43091a4803 (request APPLICATION_C
2016.04.03 11:40:59 5: SW: 06
2016.04.03 11:40:59 5: ZWDongle_0 dispatch 000400121a9881b7b6bf8b944a12d26d1885617fe33059fe688d43091a4803
2016.04.03 11:40:59 4: CMD:APPLICATION_COMMAND_HANDLER ID:12 ARG:1a9881b7b6bf8b944a12d26d1885617fe33059fe688d43091a4803 CB:00
2016.04.03 11:40:59 4: CMD:APPLICATION_COMMAND_HANDLER ID:12 ARG:063105012200b9 CB:00
2016.04.03 11:40:59 1: PERL WARNING: Argument "18.5 C" isn't numeric in numeric gt (>) at (eval 1056) line 1.
2016.04.03 11:40:59 1: PERL WARNING: Argument "18.5 °C" isn't numeric in numeric gt (>) at (eval 1057) line 1.
2016.04.03 11:40:59 1: PERL WARNING: Argument "18.5 °C" isn't numeric in numeric gt (>) at (eval 1058) line 1.
...
2016.04.04 12:02:37 2: ZWave get ZW_Sirene_A2 battery
2016.04.04 12:02:37 5: ZWDongle_Write 0013120280022577 (cb838b79)
2016.04.04 12:02:37 5: SW: 0109001312028002257725
2016.04.04 12:02:37 4: ZWDongle_ReadAnswer arg:battery regexp:^00040012..80
2016.04.04 12:02:37 5: ACK received, WaitForAck=>2 for 0109001312028002257725
2016.04.04 12:02:37 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.04.04 12:02:37 5: SW: 06
2016.04.04 12:02:37 5: ZWDongle_0 dispatch 011301
2016.04.04 12:02:38 5: ZWDongle_ReadAnswer: select timeout
2016.04.04 12:02:39 4: no response from device, removing 0109001312028002257725 from dongle sendstack
2016.04.04 12:02:42 2: ZWave: No ACK from ZW_Sirene_A2 after 5s for sentget:13120280022577
2016.04.04 12:02:44 4: ZWDongle_Read ZWDongle_0: rcvd 0013770102c4 (request ZW_SEND_DATA), sending ACK
2016.04.04 12:02:44 5: SW: 06
2016.04.04 12:02:44 5: ZWDongle_0 dispatch 0013770102c4
2016.04.04 12:02:44 4: CMD:ZW_SEND_DATA ID:01 ARG:02c4 CB:77
2016.04.04 12:02:44 2: ZWDongle_0 transmit NO_ACK for CB 77, target ZW_Sirene_A2
2016.04.04 12:03:05 1: PERL WARNING: Argument "22.8 C" isn't numeric in numeric gt (>) at (eval 1189) line 1.
2016.04.04 12:03:05 1: PERL WARNING: Argument "18.5 C" isn't numeric in numeric gt (>) at (eval 1190) line 1.
2016.04.04 12:03:05 1: PERL WARNING: Argument "18.5 °C" isn't numeric in numeric gt (>) at (eval 1191) line 1.
2016.04.04 12:03:10 1: PERL WARNING: Argument "22.8 C" isn't numeric in numeric gt (>) at (eval 1197) line 1.
2016.04.04 12:03:10 1: PERL WARNING: Argument "18.5 C" isn't numeric in numeric gt (>) at (eval 1198) line 1.
2016.04.04 12:03:10 1: PERL WARNING: Argument "18.5 °C" isn't numeric in numeric gt (>) at (eval 1199) line 1.


Am 3.4.2016 um 11:40 kam die letzte Temperaturmeldung herein, seither herrscht Funkstille (bei der Außensirene).
(Einträge anderer Geräte hab ich aus dem Log gelöscht...)
Nachdem mir heute aufgefallen ist, daß keine aktuelle Temperatur vorliegt, hab ich ein "ZWave get ZW_Sirene_A2 battery" abgesetzt, auf das keine Antwort kam.
Siehst Du mehr im Log?

In diesem Zustand triggert das Gerät auch nicht bei Auslösung des Sabotagekontaktes, was doch auch ohne Verbindung zur Zentrale funktionieren sollte!
Für mich sieht das aus, als würde sich das Gerät, warum auch immer, aufhängen (sein Prozessor abstürzen)!

...ich hatte mal angefangen mir das anzuschauen aber mangels eines verfügbaren Update-Files erst mal nicht weiter verfolgt.
...
Daher habe ich das erst mal wieder liegen lassen, vor allem da ja noch einige Sachen in Security und dem ZWCul offen sind.

Hallo Andreas!

Falls Du es doch noch einmal probieren willst, gibt es hier: http://new.zwave.eu/ota.php ein FW-File, ganz ohne NDA, zum herunterladen.
Aber auch ich bin der Menung, daß eine funktionierende Security derzeit wichtiger ist als die Möglichkeit des FW-Update.


LG
Rainer

[krikan]

Siehst Du mehr im Log?

Sehe auch nur, dass keine Antwort kommt. Habe aber von SECURITY, das im Log auftaucht, keine Ahnung.
Empfängt ZWDongle in dem gelöschten Log-Zeitraum noch andere Geräte?
Musst Du jetzt die Sirene stromlos machen, damit die wieder funktioniert?

Btw. Vermute die PERL WARNING könnten aus obigen userReadings kommen. Nutze mal ReadingsNum statt ReadingsVal und schau, ob die dann weg sind.

[rudolfkoenig]

Ich vermute, Andreas meinte mit "Security und ZWCUL" die Moeglichekeit auch mit dem CUL die Klasse Security verwenden zu koennen.
Mit dem ZWDongle sind mir keine Security-Probleme bekannt.

[gamauf]

Empfängt ZWDongle in dem gelöschten Log-Zeitraum noch andere Geräte?
Musst Du jetzt die Sirene stromlos machen, damit die wieder funktioniert?

Außer der Außensirene ist derzeit nur noch die Innensirene aktiv. Da sie von sich aus nichts sendet (hat kein Termometer eingebaut) und es auch sonst keinen Grund gab sie anzusprechen steht nichts im Log. Sie ist aber Ansprechbar:

Code Auswählen Erweitern

2016.04.04 14:29:16 2: ZWave get ZW_Sirene_I1 battery
2016.04.04 14:29:16 5: ZWDongle_Write 00130f0280022578 (cb838b79)
2016.04.04 14:29:16 5: SW: 010900130f028002257837
2016.04.04 14:29:16 4: ZWDongle_ReadAnswer arg:battery regexp:^0004000f..80
2016.04.04 14:29:16 5: ACK received, WaitForAck=>2 for 010900130f028002257837
2016.04.04 14:29:16 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.04.04 14:29:16 5: SW: 06
2016.04.04 14:29:16 5: ZWDongle_0 dispatch 011301
2016.04.04 14:29:17 5: ZWDongle_ReadAnswer: select timeout
2016.04.04 14:29:17 4: ZWDongle_Read ZWDongle_0: rcvd 001378000084 (request ZW_SEND_DATA), sending ACK
2016.04.04 14:29:17 5: SW: 06
2016.04.04 14:29:17 5: device ack reveived, removing 010900130f028002257837 from dongle sendstack
2016.04.04 14:29:17 5: ZWDongle_0 dispatch 001378000084
2016.04.04 14:29:17 4: CMD:ZW_SEND_DATA ID:00 ARG:0084 CB:78
2016.04.04 14:29:17 4: ZWDongle_0 transmit OK for CB 78, target ZW_Sirene_I1
2016.04.04 14:29:17 4: ZWDongle_Read ZWDongle_0: rcvd 0004000f03800346 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.04.04 14:29:17 5: SW: 06
2016.04.04 14:29:17 5: ZWDongle_0 dispatch 0004000f03800346
2016.04.04 14:29:17 4: CMD:APPLICATION_COMMAND_HANDLER ID:0f ARG:03800346 CB:00
...
2016.04.04 14:33:01 2: ZWave get ZW_Sirene_A2 smStatus
2016.04.04 14:33:01 5: ZWDongle_Write 001312029840257a (cb838b79)
2016.04.04 14:33:01 5: SW: 0109001312029840257a72
2016.04.04 14:33:01 5: ACK received, WaitForAck=>2 for 0109001312029840257a72
2016.04.04 14:33:01 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.04.04 14:33:01 5: SW: 06
2016.04.04 14:33:01 5: ZWDongle_0 dispatch 011301
2016.04.04 14:33:03 4: no response from device, removing 0109001312029840257a72 from dongle sendstack
2016.04.04 14:33:04 4: ZWDongle_Read ZWDongle_0: rcvd 00137a01015b (request ZW_SEND_DATA), sending ACK
2016.04.04 14:33:04 5: SW: 06
2016.04.04 14:33:04 5: ZWDongle_0 dispatch 00137a01015b
2016.04.04 14:33:04 4: CMD:ZW_SEND_DATA ID:01 ARG:015b CB:7a
2016.04.04 14:33:04 2: ZWDongle_0 transmit NO_ACK for CB 7a, target ZW_Sirene_A2
2016.04.04 14:33:06 2: ZWave: No ACK from ZW_Sirene_A2 after 5s for sentset:1312029840257a
2016.04.04 14:33:08 3: ZW_Sirene_A2: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd

Ja, damit die Außensirene wieder funktioniert muß ich sie aus- und wieder einschalten (Stromlos machen).

Btw. Vermute die PERL WARNING könnten aus obigen userReadings kommen. Nutze mal ReadingsNum statt ReadingsVal und schau, ob die dann weg sind.

Die PERL WARNINGs kommen von einer ReadingsGroup die Temperaturmeßwerte zusammenfaßt. Die Geräte hängen an den Temperaturwert ein "C" dran. Hab noch nicht herausgefunden, wie ich das wegbekomme. Es ist warscheinlich das "valueStyle" Attribut in dem ich "$VALUE" mit einem Zahlenwert vergleiche. "$VALUE" endet auf " C", was keine Zahl ist...
(Das hat natürlich nichts mit der ZWave Kommunikation zu tun, ich hab die Logzeilen aber drin gelassen, damit sie Dir vielleicht auffallen und Du möglw. einen Tipp für mich hast!   )

[gamauf]

...
Mit dem ZWDongle sind mir keine Security-Probleme bekannt.

Sehr gut!
Danke!

[krikan]

Sie ist aber Ansprechbar:
...
Ja, damit die Außensirene wieder funktioniert muß ich sie aus- und wieder einschalten (Stromlos machen).

Also kein hängengebliebenes Dongle.
Dann bin ich am Ende mit (Nebel)Tipps 
Firmwareupdate wäre wohl sinnvoll. Evtl. hilft das. Ansonsten bleibt nur eine andere Schlußfolgerung...

Die PERL WARNINGs kommen von einer ReadingsGroup die Temperaturmeßwerte zusammenfaßt.

@Rudi: Sorry

[A.Harrenberg]

Hi Rainer,

Hallo Andreas!

Falls Du es doch noch einmal probieren willst, gibt es hier: http://new.zwave.eu/ota.php ein FW-File, ganz ohne NDA, zum herunterladen.
Aber auch ich bin der Menung, daß eine funktionierende Security derzeit wichtiger ist als die Möglichkeit des FW-Update.

Danke, aber das nutzt mir nichts da ich das dazugehörende Gerät ja nicht habe...

Ich schau mir das File aber trotzdem bei Gelegenheit mal an um zu sehen ob da die Checksumme mit in dem File drin steht oder ob man die extern berechnen muss.

Gruß,
Andreas.

[gamauf]

Hallo!
Erst einmal danke für Eure Tipps.

Ich fasse nochmal die von mir festgestellten "Problemchen" zusammen:

• Temperaturen unter 0°C:
  0°C wird als 2359°C, Temperaturen unter 0 mit entsprechend "kleineren" Werten angezeigt.
  Workaround: kann durch ein Userreading im FHEM korigiert werden.
  Fix: forhandenes FW Update, das dieses Problem beheben soll kann mit FHEM nicht eingespielt werden.
• Parameter 6 "auto OFF" kann nicht gesetzt werden.
  Hab mehrmals versicht, sowohl über "set <Device> ConfigAutoOFF 2" als auch "set <Device> configByte 6 2" den Parameter vom default "0" auf "2" zu ändern, nach einem "get <Device> configAutoOFF" oder auch "get <Device> config 6" oder "get <Device> configAll" ist es immer noch auf "0"
  Workaround: aus FHEM programmatisch nach 2 Minuten wieder abschalten
  Fix: keiner bekannt
• egal was in Parameter 4 (Send unsolicited temperature report after N wake up) steht die Sirene meldet nur neue Temperaturwerte wenn sich die gemessene Temperatur um mehr als in Parameter 3 angegeben Ändert.
  Workaround: Watchgdog, der wenn der letzte gemeldete Temperaturwert älter als eine Stunde ist die aktuelle Temperatur abfragt.
  Fix: keiner bekannt
• Das Gerät meldet von sich aus keinen Batteriestand, außer nach einem der oben genannten Hänger ein "battery: low". Wenn mann unmittelbar darauf (hab ich automatisiert) den Batteriestand abfragt ("get <Device> battery") wird "battery: 100 %" gemeldet. Hab von dem Gerät auf "get <Device> battery" noch nie eine andere Antwort als "battery: 100 %" bekommen!
  Workaround: keiner bekannt
  Fix: keiner bekannt
• Und zum Schluß der hier viel besprochene Hänger.
  Wie äußert sich so ein Hänger:
  
  
  
  • Keine Reaktion auf Anfragen/Komandios von FHEM
  • Sendet auch vin sich aus keine Meldungen (Temperatur, Sabotagemeldung, etc.)
  • es ist ein leises Pfeifen zu hören
  • Die Blitz-LEDs glimmen schwach
  • Nimmt man das Gerät von der Wandhalterung geht es nicht los, obwohl es entsprechend konfiguriert ist (parameter 1 set to "0", parameter 5 set to "2")
  Um die Sirene wieder zum Leben zu erwecken kan man entweder
  
  
  
  • Warten
  oder
  
  • Das Gerät von der Wand nehmen, es aufschrauben, es ausschalten und wieder einschalten, worauf der Alarm los geht, wenn man es nicht auf der Wandhalterung hat (oder dies durch einen Magneten an der richtigen Stelle vortäuscht)!
  Der Popp Support sieht zwei möglich Ursachen:
  
  
  
  • Bei direkter Sonneneinstrahlung kann das Gerät über 80°C bekommen was an der grenze der Spezifikation des ZWave Chips ist.
    Man hat mir angeboten das Gerät zurückzukaufen
    (Mein Gerät hat erst Temperaturen bis knapp über 40°C gemeldet)
  • Fehlender FLIRS Support des Controllers
  
  So weit ich weiß ist FLIRS eine Methode wie der Controller ein Batterie-betriebenes Gerät sofort aufwecken kann.
  Würde FHEM die Sirene nicht aufwecken können, würde das Gerät wenige Minuten nach dem Einschalten auf FHEM nicht mehr reagieren. Sehr wohl würde es aber von sich aus Meldungen an FHEM absetzen können: Temperatur Meldungen Sabotage-Alarm, etc., bzw. unabhängig von FHEM Losheulen wenn man es von der Wand nimmt. Das ist aber bei einem "Hänger" nicht der Fall! Solange sich die Sirene nicht aufgehängt hat kann FHEM aber sehr wohl Temperatur abfragen (geschieht stündlich) oder auch sonst mit dem Gerät kommunizieren. Auch Stunden nach dem Einschalten.
  Fehlender FLIRS Support klingt für mich daher nicht plausibel.
  
  Ich vermute viel eher ein Problem mit der Stromversorgung bzw. dr Ladeschaltung des Accus:
  Habe den Eindruck, daß wen zu viel Licht auf das große Solar-Panel fällt die Hänger auftreten.
  Daher experimentiere ich derzeit damit die Solarzellen teilweise abzudecken. Habe den Eindruck, daß die Hänger jetzt seltener auftreten.
  Im Winter wird man die Abdeckung aber vermutlich wieder entfernen oder reduzieren müssen! Vielleicht wären auch Lamellen die bei höherem Sonnenstand abschatten, bei flachem Sonnenstand aber direkte Bestrahlung zulassen eine Möglichkeit.
  Hier muß ich noch weiter experimentieren...
  Halte Euch auf dem Laufenden.
  
  

LG
Rainer

[krikan]

Dein ZWave.me UZB1 kann grds. FLIRS. Es sei denn, er ist defekt oder inkompatibel zur Popp Sirene. Letzteres würde mich wundern, da zwave.me auch bei der Sirene mitmischt.
Nachdem mein Popp Rauchmelder irrtümlich die modelId Deiner Sirene hat (https://forum.fhem.de/index.php/topic,53315.msg455109.html#msg455109) bin ich leicht hinsichtlich Popp verunsichert...

[gamauf]

Nachtrag zum Problem Nr. 2:

• Parameter 6 "auto OFF" kann nicht gesetzt werden.
  Hab mehrmals versicht, sowohl über "set <Device> ConfigAutoOFF 2" als auch "set <Device> configByte 6 2" den Parameter vom default "0" auf "2" zu ändern, nach einem "get <Device> configAutoOFF" oder auch "get <Device> config 6" oder "get <Device> configAll" ist es immer noch auf "0"
  Workaround: aus FHEM programmatisch nach 2 Minuten wieder abschalten
  Fix: keiner bekannt

Laut Popp Support ligt der Fehler ausschlißlich an der Abfrage des Parameter 6; es wird immer "0" zurückgemeldet. Aber der gesetzte Wert wird angeblich vom Gerät berücksichtigt!
Also ein "set <Device> ConfigAutoOFF 2" bewirkt angeblich sehr wohl, daß sich die Sirene nach zwei Minuten wieder abstellt, auch wenn bei "get <Device> configAutoOFF" immer "0" zurückgegeben wird.

[krikan]

d.h. Firmwarefehler und Firmware-Update kommt?

[gamauf]

d.h. Firmwarefehler und Firmware-Update kommt?

davon hat Popp Support nichts gesagt:

> One other "minor problem" I forgot to mention is, that I am not able
> to set parameter 6 (auto OFF)
> after setting it to "2" and the queering its value the device always
> returns "0"
> Also it never had the default value of  "5" mentioned in the manual.
this is true, we found this but too. The value is set but the wrong
value is returned.

Auch zu den Problemen 3 & 4 hat er sich nicht geäußert und auf mein letztes Nachfrage-Mail am 9.6. nicht mehr geantwortet.
Ich bin pessimistisch ... mein ganz persönlicher Eindruck ist, daß das Interesse von Popp an diesem Produkt schwindet...

...aber vielleicht sind sie motivierter die Probleme zu beheben, wenn sich mehr Kunden bei Popp melden...

[krikan]

Hallo Rainer!

Da ich versuche ein wenig Durchblick bei der CC FIRMWARE_UPDATE_MD zu bekommen, waere es für mich hilfreich, wenn ich die Hexantwort der Popp Sirene auf die nachfolgende Abfrage der Firmwareinfos haette:

Code Auswählen Erweitern

get <ZWDongle> raw 13[nodeIdHex]027a0125

Könntest Du das bitte machen, wenn Du die Sirene noch in FHEM eingebunden hast?

[nodeIdHex] muss durch die entsprechende hexadezimale NodeId (2stellig) ersetzt werden. Das Ergebnis steht anschließend im Reading UNPARSED der Device-Details der Sirene oder bei verbose 5 bei ZWDongle auch im Log.

Die Abfrage liefert Infos zur manufId, FirmwareId, FirmwareChecksumme u.a. .

Danke und Gruß, Christian

PS: Falls Du keine Zeit/Lust dazu hast, ist das auch Ok .

[gamauf]

Hallo Christian!

Die Antwort im "UNPASED" Reading:
FIRMWARE_UPDATE_MD 0e7a0201150101b5220100001e0000

LG
Rainer