POPP Outdoor Siren (POPE005107)

[gamauf]

Hallo!

Hatte jetzt eine Weile keine Zeit mich um die Sirene und ihr Minustemperaturen-Problem zu kümmern. Jetzt zwingt mich aber ein neues Problem mich mit der Sirene zu beschäftigen:

Habe mir im November '15 zwei dieser Sirenen gekauft und die erste gleich in Betrieb genommen. Sie hat auch über den Winter gut funktioniert.
Aber seit erstem März verliert FHEM die Verbindung zur Sirene:

ZW_Sirene_A1.log:

Code Auswählen Erweitern

2016-03-25_11:33:18 ZW_Sirene_A1 SEND_DATA: failed:00
2016-03-25_11:33:18 ZW_Sirene_A1 TRANSMIT_NO_ACK

fhem.log:

Code Auswählen Erweitern

2016.03.25 11:33:17 2: ERROR: cannot SEND_DATA to ZW_Sirene_A1: transmit queue overflow
2016.03.25 11:33:18 3: ZW_Sirene_A1: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.03.25 11:33:18 2: ZWDongle_0 transmit NO_ACK for CB 05, target ZW_Sirene_A1

In diesem Zustand leuchten die Blitz-LEDs der Sirene schwach und es ist ein leises Pfeifen zu hören. Ich muß dann die Sirene vom Halter nehmen, aufschrauben, am internen Schalter ausschalten, wieder einschalten und den Sabotagealarm quittieren (das ganze am Besten mit Gehörschutz!).
Beim Einschalten wird einmal "battery: low" gesendet, danach meldet die Sirene aber gleich wieder "battery: 100 %". Ich messe eine Batteriespannung von über 8V. Bei einer Nennspannung von 7,4V ist das wohl mehr als geladen.

Auch die zweite Sirene, die den Winter in der Wohnung verbracht hat, zeigt nach wenigen Tagen im Freien dieses Verhalten.

Als eine Ursache könnte ich mir die im Frühling höheren Temperaturunterschiede zwischen Tag und Nacht vorstellen, wodurch die internen Klemmen, oder eine Lötstelle nicht mehr richtig kontaktieren.

Wie kann ich ein Software-Problem ausschließen?
Das Problem ist das erste Mal am 1.3. aufgetreten nachdem ich am 28.2.2016 ein FHEM-Update eingespielt habe. auch die Z-Wave Innensirene hat im März 6 mal:"

Code Auswählen Erweitern

ZWDongle_0 transmit NO_ACK for CB 08, target ZW_Sirene_I1" gemeldet, was vorher nie vorkam! Die Innensirene funktioniert dann aber von alleine wieder.
Andere Z-Wave Geräte hab ich derzeit nicht.

Könnte das Verhalten durch eine Änderung Ende Februar in 00_ZWDongle.pm oder 10_ZWave.pm augelöst worden sein?

Noch eine Info: Die Außensirenen kommunizieren verschlüsselt, die Innensirene (derzeit) nicht.


LG
Rainer

[gamauf]

..noch 'was anderes:
mir ist inzwischen aufgefallen, daß die längeren Zeilen in meinen Änderungen für sie fhem_zwave_deviceconfig.xml.gz, die ich hier https://forum.fhem.de/index.php/topic,42736.msg367326.html#msg367326 gepostet habe, abgeschnitten sind.
Daher poste ich im Dateianhang nochmals den vollständigen Eintrag mit der Bitte die fhem_zwave_deviceconfig.xml.gz zu korrigieren.
Danke!!

[krikan]

Daher poste ich im Dateianhang nochmals den vollständigen Eintrag mit der Bitte die fhem_zwave_deviceconfig.xml.gz zu korrigieren.

Habe ich eingecheckt. Ab morgen per update oder heute aus dem SVN.
Gruß, Christian

[gamauf]

Habe ich eingecheckt. Ab morgen per update oder heute aus dem SVN.
Gruß, Christian

Danke!!
LG
Rainer

[krikan]

Zu Deinem eigentlichen Thema:

Ein Log der Fehlersituation mit verbose 5 bei ZWDongle mit den aktuellen Modulversionen könnte bei der Klärung evtl. helfen. Die Infos sind mMn eigentlich zu schmal.

Softwareproblem würde ich versuchen auszuschließen, indem ich alten Stand aus svn oder restoreDir der lokalen Installation zurückspiele und teste. Andererseits sollten die neuesten Module (ohne SECURITY) noch einmal deutlich besser auch extreme Funksituationen meistern als zu Beginn des Jahres; so zumindest meine Einschätzung/Tests.

Hast Du optimale Funkbedingungen? D.h. gibt es überhaupt Router in Deinem ZWave-Netz?
Witterung/Position hat auch Einfluß auf Funkkommunikation. Darauf würde ich bei NO_ACK tippen.

Aufgrund Deiner Infos und der alten Temperaturprobleme geht man Verdacht derzeit noch in eine andere Richtung....

[gamauf]

So, wenn ich jetzt schon dabei bin schreib ich gleich alles was mit zu dieser Sirene so am Herzen liegt:

Firmware-Update:
Habe den Popp-Support nach Hash für Firmware-File gefragt um fehlerfreien Download überprüfen zu können. Antwort war: brauch ich nicht; FW-File ist signiert. Wenn sich bei Download Fehler eingeschlichen hat wäre Signatur ungültig und Gerät verweigert Installation.
Daraus schließe ich, daß das Programmieren eines OTA-FW-Update im FHEM keine Gefahr des "Bricken" des Z-Wave Gerätes birgt.
Ich weiß zwar nicht aus welcher Befehlsfolge so ein FW-Update besteht, stelle es mir aber ganz naiv so vor:
man schickt den Befehl "update FW", danach schickt man die FW-Datei.
Ist der Befehl falsch tut das Gerät nichts.
Kommt die FW-Datei nicht richtig an, dann stimmt die Signatur nicht, das Gerät tut auch nichts.
Erst wenn man alles richtig macht tut das Gerät etwas: es aktualisiert seine FW!
Wie seht Ihr das?

Minustemperaturen-Problem im FHEM korrigieren:
(Die Sirene hat auch ein Thermometer eingebaut; Minus-Temperaturen werden jedoch ab 2359 °C abwärts angezeigt! 0°C wird als 2359 °C angezeigt)
Hab mir als Work-around einen Dummy per Notify mit folgender Formel befüllt:

Code Auswählen Erweitern

{
my $x;
my $AbsolutNull;
my $KorrekturWert;
$AbsolutNull=-273.15;
$KorrekturWert=2359;
$x=$EVTPART1;
if($x > ($KorrekturWert + $AbsolutNull)) {    #um den positiven Temp.bereich nicht unnötig einzuschränken ;-)
$x -= $KorrekturWert;
$x = int(100*$x)/100;
fhem("set Temperatur_Dummy $x°C"); }
else {
fhem("set Temperatur_Dummy $x°C");; }
}
(2086,85°C entspricht -273,15°C = 0 K; kälter gehts nicht!)
Aber es wäre natürlich bequemer wenn FHEM gleich die richtigen Werte ins Reading und ins Log schreibt.
Hätte mir ein Attribut für Z-Wave Geräte mit dem Korrektur-Wert vorgestellt. Ist das Attribut nicht vorhanden, oder null werden die Temperaturwerte des Gerätes 1:1 übernommen. ist Das Attribut mit einem anderen Korrektur-Wert befüllt wird obige Formel zur Korrektur der Temperaturwerte herangezogen.
Ich verstehe leider die ZWave Module zu wenig um diese Änderungen selber einzubauen. Für den Programmierer des Moduls ist es aber wahrscheinlich nur eine Kleinigkeit. Oder?


LG
Rainer

[gamauf]

Zu Deinem eigentlichen Thema:

Ein Log der Fehlersituation mit verbose 5 bei ZWDongle mit den aktuellen Modulversionen könnte bei der Klärung evtl. helfen. Die Infos sind mMn eigentlich zu schmal.

ist klar, werde das Loggong hochdrehen...

Softwareproblem würde ich versuchen auszuschließen, indem ich alten Stand aus svn oder restoreDir der lokalen Installation zurückspiele und teste. Andererseits sollten die neuesten Module (ohne SECURITY) noch einmal deutlich besser auch extreme Funksituationen meistern als zu Beginn des Jahres; so zumindest meine Einschätzung/Tests.

mein ältester Eintrag im Restore dir ist vom 4.3.
hab zu oft aktualisiert!

Hast Du optimale Funkbedingungen? D.h. gibt es überhaupt Router in Deinem ZWave-Netz?
Witterung/Position hat auch Einfluß auf Funkkommunikation. Darauf würde ich bei NO_ACK tippen.

Den USB-Stick und die Sirene trennen keine fünf Meter und eine Ziegelwand...
Der USB-Stick ist zwar seit Mite Jänner etwas weiter weg von der Sirene, aber bis Anfang März hats ja problemlos funktioniert.
Die Innensirene liegt zwischen Controller und Außensirene. Können Geräte die nicht verschlüsseln die verschlüsselte Kommunikation für andere Geräte routen?
Wie sehe ich ob geroutet wird? In der neighborList haben sich die Geräte gegenseitig.
Z-Wave Geräte zeigen keine RSSI an. Gibt es eine Möglichkeit die Signalstärke zu ermitteln?

Aufgrund Deiner Infos und der alten Temperaturprobleme geht man Verdacht derzeit noch in eine andere Richtung....

und zwar?
Mit "alten Temperaturprobleme" meinst du, daß die Minustemperaturen über 2000°C angezeigt werden?
Das ist ein, von Popp bestätigter, FW-Bug.

Danke für Deine Antwort!

Schönen Abend
Rainer

[rudolfkoenig]

Für den Programmierer des Moduls ist es aber wahrscheinlich nur eine Kleinigkeit.

Nicht unbedingt, wenn es generisch sein soll. @krikan: sollen wir sowas auf die TODO setzen?

Alternativ macht man es mit userReadings, ist nicht so kompliziert:

Code Auswählen Erweitern

attr POPE005107 userReadings tmpCorr:temperature { my $t = ReadingsVal("POPE005107","temperature",0);; ($t > 2086.85 ? round($t-2359,2) : $t)."°C"}

Wobei ich zwischen Zahl und °C ein Leerzeichen lassen wuerde.

hab zu oft aktualisiert!

oder "attr global restoreDirs" ist zu klein. Bleibt noch
https://sourceforge.net/p/fhem/code/11149/log/?path=/trunk/fhem/FHEM/10_ZWave.pm

Wie sehe ich ob geroutet wird?

Mir faellt nur ZWCUL ein

[krikan]

Nicht unbedingt, wenn es generisch sein soll. @krikan: sollen wir sowas auf die TODO setzen?

Na, dann bin ich es eben Schuld  Hatte mich extra zurückgehalten, um anderen die Entscheidung zu überlassen...
Kurz: Nein.
Lang: Das Problem beruht doch auf einem Firmwarebug, der durch ein bereits existentes Firmwareupdate behoben werden kann. Wenn wir jetzt auch noch beginnen so etwas zu behandeln, fehlt die Zeit für WichtigeresSpannenderes. Einfache Lösung gibt es ohne Modulanpassung über userReadings. Von mir aus packe ich das ins Wiki, wenn ich die Info bekomme, welche Firmwareversion betroffen ist und ab wann behoben.

[gamauf]

Hallo!

Danke für Eure Antworten!
Werde das mit dem userReading probieren. Sollte damit auch ohne Modulanpassung auskommen.
Ist die Schreibweise "IF-Abfrage ? Then-Block : Else-Block" Perl oder ein FHEM Spezifikum?

...
Mir faellt nur ZWCUL ein

Habe keinen CUL (für Z-Wave) sondern einen Z-Wave Me USB Stick.
In der neighborList hat jedes Gerät die anderen. Im nodeInfo steht bei allen drei Geräten "ROUTING_SLAVE sleeping frequentListening:64 beaming:16 routing 40kBaud Vers:4 Security:0"
(hmmmm... die zwei Außensirenen sollten Seurity aktiviert haben!??)
Aber welche Route das Funksignal nimmt kann ich beim ZWDongle nicht herauslesen.

Danke für Eure Unterstützung!

LG
Rainer

[krikan]

Hallo Rainer!

"ROUTING_SLAVE sleeping frequentListening:64 beaming:16 routing 40kBaud Vers:4 Security:0"

Steht für FLIRS (batteriebetriebene) ZWave-Geräte. FLIRS-Geräte sind keine Router (leiten keine Nachrichten weiter) und helfen Dir nicht die Stabilität des Netzes zu verbessern. Also muss der Controller mit den Sirenen direkt Kontakt haben, sonst bricht die Verbindung zusammen. Bei ZWave-Geräten würde ich bei 5m mit Wand auf Kommunikationsprobleme tippen. Bei Zwave+ muss das nicht so sein, ist aber nicht auszuschließen. Ein ZWave-Netz ohne netzgespeiste Geräte ist grds. suboptimal. Ich behaupte sogar frech, das ist einer der größten Fehler, der bei  ZWave immer wieder gemacht wird.

(hmmmm... die zwei Außensirenen sollten Seurity aktiviert haben!??)

Kannst Du nicht aus der nodeInfo schließen. Dort besteht noch Verbesserungspotential, das auf meiner Todo verweilt.

Aber welche Route das Funksignal nimmt kann ich beim ZWDongle nicht herauslesen.

Korrekt. Aber da Du keine Router hast bleibt nur direkte Kommunikation.

Experimentieren kannst Du bzgl. der Signalqualität mit den Funktionen der CC Powerlevel. Gibt zumindest eine grobe Abschätzung. Habe das aber nie mit FLIRS-Geräten getestet und mit anderen Geräten trat hier vereinzelt ein Hängenbleiben des Gerätes auf. Also evtl. Ohrschutz anlegen  .

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.

Gruß, Christian

PS: Ist Perl.

[gamauf]

Hallo Christian!

Ich will's nicht verschreien, aber seit ich das Logging des ZW-Dongles hochgedreht hab, hängt sich die Sirene nicht mehr auf. Aber es hat die letzten Nächte auch nicht mehr so stark abgekühlt...

Meine (3) Geräte sind alle ZWave+

Die Funkverbindung hat drei Monate lang auch ohne Router gut funktioniert.
Mir ist schon klar, daß ZWave als Mesh-Netzt konzipiert ist, aber da anscheinend nur (Strom-)Netz-betriebene Geräte als Router fungieren, würde meine Alarmanlage bei Stromausfall nicht mehr funktionieren! (FHEM hängt an der USV und läuft bei Stromausfall daher noch einige Zeit weiter.)

Deine letzten Sätze verstehe ich nicht ganz, da ich nicht weiß wofür "CC" steht. Bitte um Aufklärung!

Es ist schon klar und nachvollziehbar, daß Ihr (die, die an der Entwicklung von FHEM mitarbeiten) keine (größeren) Aufwände treibt die nur einem Einzelnen zu gute kommen.
Den Bedarf fürs FW-Update hätte ich größer eingeschätzt. Aber wenn es, wie Du sagst, tatsächlich erst ein Gerät gibt für das ein Update zur Verfügung steht und die Zahl der Benutzer dieses Gerätes sich auch noch recht in Grenzen hält (wie man an der Beteiligung in diesen Thread sieht), gibt es derzeit sicher höher priorisierte Tasks.

Welche Sirenen verwenden andere Leute?
Diese hier hat doch einige Vorteile:

• Kabellos - keine Stemmarbeiten, einfach zu installieren
• Batteriebetrieben - funktioniert auch bei Stromausfall
• Solarzellen zum Aufladen der Batterie - kein Batterietausch notwendig

Gibt es ZWave Repeater die ich über die Ethernet-Verkabelung mit Strom versorgen könnte? (Also mit Niederspannung, keine 230V)

So bin am Ende etwas abgeschweift...

Danke für Deine Antworten!

LG
Rainer

[krikan]

Hallo Rainer!

Worauf die nicht so starke Abkühlung und bleibende Funktionsfähigkeit jetzt hindeutet, wissen wir dann leider immer noch nicht. Entweder verträgt die Sirene keine starken Temperaturschwankungen oder die Funkverbindung war bei der Witterung besser oder FHEM hat keinen Fehler gemacht oder....

CC steht für Command Class. Die CC Powerlevel dient der Ermittlung der Qualität der Funkverbindung. Details findest Du in der commandref zum ZWave-Modul oder hier im Forum vergraben. Deine Popp-Sirene unterstützt die Command Class laut pepper1.

Hier wird auch für Einzelne entwickelt , wenn jemand Spass daran hat. Hoffe und warte einfach, wenn es nicht drängt. Manchmal/Oft geht es schneller als man denkt. Bevor der falsche Eindruck entsteht: Bin definitiv kein Developer.

Nutze selbst eine netzbetriebene AEOTEC Innensirene, die eine Backup-Batterie hat. Selbst wenn der Strom ausfällt, lärmt die weiter UND routet. Letzteres habe ich selbst getestet. Wie lange, kann ich aber nicht sagen.

Kenne keinen solchen Repeater. Einziger mit bekannter, halbwegs aktueller Repeater ist von AEOTEC. Der hat aber kein ZWave+ und macht Dir afaik die +-Funkeigenschaften der Geräte ggfs. kaputt.

Gruß, Christian

[gamauf]

Hallo Christian!

Ist das diese: Aeotec Sirene ZW080-BI - Z-Wave Plus

Und die routet auch im Batteriebetrieb?
Wäre dann die Überlegung wert das Gerät als Router einzusetzen!

Danke für die Infos!

LG
Rainer

[krikan]

Diese: http://products.zwavealliance.com/products/1136

Und die routet auch im Batteriebetrieb?

Nach meinen Feststellungen: Ja
Hat mich bei Reichweitentest zur Verzweifelung getrieben. Ich wusste nicht, warum mein batteriebetriebener Sensor plötzlich Riesenreichweite hatte, obwohl alle netzbetriebenen Router ausgesteckt/stromlos waren. Erst Sirene im Metall-Kochtopf brachte plausible Rechweiten. -> Schlußfolgerung siehe oben
Wie lange eingebaute Backup-Batterie (Akku) hält kann ich aber nicht sagen.
Letzte Gewissheit bietet Dir nur Auskunft von AEOTEC. Die antworten normalerweise auch kompetent und zügig. Wenn Du fragst, bitte berichten.

Wäre dann die Überlegung wert das Gerät als Router einzusetzen!

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

Gruß, Christian