Seit Anpassung der WH3080 Daten kommt es zu einem Fehler #17

sidey79 · 2019-07-02T19:31:39Z

Im commit 7d02962 wurden die Daten für die WH3080 angepasst:

SIGNALduino_TOOL/FHEM/lib/SD_Device_ProtocolList.json

Lines 177 to 184 in 6e6aa4b

    
           {"name":"WH3080", "id":"9", "data": [ 
        
               { 
        
                 "dmsg":"P9#FF7C845508D87403", "comment":"reconstructed bit 1", "user":"Ralf9", 
        
                 "internals": {"DEF":"WH1080", "NAME":"WH1080"}, 
        
                 "readings": {"state":"UV: 4 Lux: 57970 ", "Lux":"57970", "UV":"4", "id":"200"}, 
        
                 "rmsg":"MU;P0=-1424;P1=1417;P2=-1058;P3=453;P4=-24774;P6=288;P7=-788;D=01212121232343232323232323232123232323232121232121212123212121232123212321232121212123212121232321232321212121232323212321212121212121212323467323232323232323212323232323212123212121212321212123212321232123212121212321212123232123232121212123232321232121;CP=3;R=247;O;" 
        
               } 
        
             ]

Diese Daten werden für den automatischen Test nun auch verwendet, da der Wert internals gesetzt ist.

Getestet wurde gegen den Modulstand commit 7c6e785456a1c105a7720e5f0b89c8d0566c8da1.

package lib::SD_ProtocolData;
	our $VERSION = '1.05';

Anbei das Log:

2019.07.02 21:26:42 5: Starting notify loop for dummyDuino, 1 event(s), first is dummyDuino 4: dummyDuino/msg get raw: \002MU;P0=-1424;P1=1417;P2=-1058;P3=453;P4=-24774;P6=288;P7=-788;D=01212121232343232323232323232123232323232121232121212123212121232123212321232121212123212121232321232321212121232323212321212121212121212323467323232323232323212323232323212123212121212321212123212321232123212121212321212123232123232121212123232321232121;CP=3;R=247;O;\003
2019.07.02 21:26:42 5: End notify loop for dummyDuino
2019.07.02 21:26:42 4: dummyDuino/msg get raw: �MU;P0=-1424;P1=1417;P2=-1058;P3=453;P4=-24774;P6=288;P7=-788;D=01212121232343232323232323232123232323232121232121212123212121232123212321232121212123212121232321232321212121232323212321212121212121212323467323232323232323212323232323212123212121212321212123212321232123212121212321212123232123232121212123232321232121;CP=3;R=247;O;�
2019.07.02 21:26:42 5: Starting notify loop for dummyDuino, 1 event(s), first is dummyDuino 4: dummyDuino: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2019.07.02 21:26:42 5: End notify loop for dummyDuino
2019.07.02 21:26:42 4: dummyDuino: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2019.07.02 21:26:42 5: Starting notify loop for dummyDuino, 1 event(s), first is dummyDuino 5: dummyDuino: 0. try, regex ((?:)((?:32|32){43,})) did not match
2019.07.02 21:26:42 5: End notify loop for dummyDuino
2019.07.02 21:26:42 5: dummyDuino: 0. try, regex ((?:)((?:32|32){43,})) did not match
2019.07.02 21:26:42 5: Starting notify loop for dummyDuino, 1 event(s), first is dummyDuino 4: dummyDuino: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2019.07.02 21:26:42 5: End notify loop for dummyDuino
2019.07.02 21:26:42 4: dummyDuino: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2019.07.02 21:26:42 5: Starting notify loop for dummyDuino, 1 event(s), first is dummyDuino 5: part is 323232323232323212323232323212123212121212321212123212321232123212121212321212123232123232121212123232321232121212121212121232 starts at position 13 and ends at 139
2019.07.02 21:26:42 5: End notify loop for dummyDuino
2019.07.02 21:26:42 5: part is 323232323232323212323232323212123212121212321212123212321232123212121212321212123232123232121212123232321232121212121212121232 starts at position 13 and ends at 139
2019.07.02 21:26:42 5: Starting notify loop for dummyDuino, 1 event(s), first is dummyDuino 5: dummyDuino: Starting demodulation ( regex: (?:)((?:32|12){60,}) Pos 0) length_min_max (60..120) length=63
2019.07.02 21:26:42 5: End notify loop for dummyDuino
2019.07.02 21:26:42 5: dummyDuino: Starting demodulation ( regex: (?:)((?:32|12){60,}) Pos 0) length_min_max (60..120) length=63
2019.07.02 21:26:42 5: Starting notify loop for dummyDuino, 1 event(s), first is dummyDuino 5: dummyDuino: dispatching hex: P9#FF7C845508D87402
2019.07.02 21:26:42 5: End notify loop for dummyDuino
2019.07.02 21:26:42 5: dummyDuino: dispatching hex: P9#FF7C845508D87402

The text was updated successfully, but these errors were encountered:

sidey79 · 2019-07-03T20:10:57Z

@HomeAutoUser

Ich weiss nicht, ob Du eine Benachrichtigung bekommst wenn ich das issue aufmache, daher schreibe ich dich sicherheitshalber direkt an

HomeAutoUser · 2019-07-03T20:17:11Z

@sidey79

Ich hab’s gerade gelesen.
Was möchtest du mir damit sagen bzw ich sehe hier mit dem MobilPhone noch nicht durch beim den Logausgaben.

Die Daten des Internals hatte ich bestimmt mit dem reconstruct Bit erzeugt. Das würde erklären wieso es bei dir nicht klappt. Oder verstehe ich den Sachverhalt falsch?

sidey79 · 2019-07-03T21:20:53Z

@HomeAutoUser

In #8 hatten wir festgelegt, dass die Angaben "rmsg" und "dmsg" validiert sind, wenn internals mit angegeben sind.

Der Test läuft unter dem angegebenen commit. Die Protokolldaten sind aktuell (version 1.05) und deutlich neuer als die Testdaten. Dennoch kommt es hier zu einer Abweichung.

Ich kann mir nicht vorstellen, mit welcher Version der Protokolldaten die Validierung vorgenommen wurde, aber das Soll Ergebnis des Tests weicht definitiv vom Ist Stand ab, wenn mit 1.05 der Test durchlaufen wird.
Sieht für mich so aus, als ob bei der Validierung etwas "schief" gelaufen ist und der angegeben Wert in dmsg mit keiner Protokolldatenversion erreicht werden kann, die bislang in dev-r34 eingeflossen ist.

HomeAutoUser · 2019-07-04T05:24:33Z

Moin Moin, ich schaue es mir an.
Ich denke @sidey79 das ich einen Schritt voraus war und sollte es so gewesen sein, dann "cleare" ich es auf die "Protokolldaten (version 1.05)" zurecht damit dein Test die richtigen Ergebnisse liefert.

Ich bin eben dran, "schnellstmöglich" jede RAWMSG / DMSG welche bei "uns" nicht klappt, als Fehler behandeln zu wollen um einen Stand anzustreben, das erstmal alle Daten darin ohne Fehler durchlaufen.
Diesen Stand würde ich als Master in SIGNALduino_TOOL dann mergen.

sidey79 · 2019-07-04T06:36:39Z

Mach dir keine Vorwürfe,

Wir sind Menschen und es passieren Fehler.
Ich wollte einfach nur darauf hinweisen, da dies aktuell der einzigste Test ist, der noch Fehler Produziert.

Wenn das Ergebnis für dieses Gerät angepasst wurde, dann laufen die Tests rmsg / dmsg alle mit einem OK durch.

Wie wir das grundsätzlich in Zukunft handhaben weiss ich leider auch noch nicht.

Die Schwierigkeit besteht ja darin, dass sich der Stand der Testdaten ändern kann, ohne dass ein Test automatisch durchgeführt wird.
Die Lösung habe ich noch nicht.

Vielleicht hilft es, wenn wir mit Tags arbeiten.
Dann wäre es zumindest eine bewusste Entscheidung die Testbedingungen zu verändern.

HomeAutoUser · 2019-07-04T06:39:12Z

Alles gut :)

Wir sind Menschen und es passieren Fehler.
Ich wollte einfach nur darauf hinweisen, da dies aktuell der einzigste Test ist, der noch Fehler Produziert.

Du meinst sicherlich, Fehler wenn die RAWMSG nicht das Ergebnis vom Internal produziert? Liege ich da richtig?

sidey79 · 2019-07-04T06:44:41Z

Wo Fehler passieren ist doch egal.
Das kann überall passieren.

In dem konkreten Fall stimmt dmsg nicht.
Das Vorhandensein des Internals ist nur ein Trigger, dass der Testfall rmsg zu dmsg prüfen durchgeführt wird.

Die Werte in internal werden derzeit in keinem Test automatisch verifiziert.
Das ist für mich ein To-Do für die Zukunft. Ebenso das festlegen ob wir repeats oder Anzahl Dispatches angeben.

HomeAutoUser · 2019-07-04T07:01:36Z

Wenn ich das richtig verstehe, prüfst du DMSG zur RAWMSG?

Meine Überlegung auf die Schnelle war soeben, ob man an einer „Kennung“ herausbekommt, hier ist noch Handlungsbedarf.

Der Gedanke dahinter ist, das ich ja eine Parallele Aufzeichnung habe wo Fehler / Differenzen vorhanden sind.

sidey79 · 2019-07-04T16:31:47Z

Was soll anhand einer Kennung herauszubekommen sein?

Ich hatte verstanden, dass wir die Felder internal nur pflegen, wenn dieser Zustand auch mit dem SIGNALduino Modul im master oder development Branch erzeugt werden kann.
Solange internal nicht gesetzt ist, findet auch kein Test statt.

Wenn internal Werte gesetzt sind gehe ich davon aus, dass sie mit dem Modul aus dev-r34 (derzeit) erreicht werden können.

Wir können auch gerne ein anderes Flag dafür einbauen.

sidey79 · 2019-07-06T18:41:46Z

@HomeAutoUser

Wie sollen wir den Fehler beheben?

Option 1: Internal entfernen
Option 2: dmsg anpassen?

sidey79 · 2019-07-07T20:23:13Z

@HomeAutoUser

Ich habe Option 1 umgesetzt: 37cc1be

Ist eher ein Workaround aber mit einer fehlerhaften Angabe macht es wenig Sinn dagegen zu testen.

HomeAutoUser · 2019-07-08T06:50:34Z

Hallo, bin gerade meist nur mobil zwecks Urlaub und sportlichen Höhepunkt.

Wie sollen wir den Fehler beheben?
Option 1: Internal entfernen
Option 2: dmsg anpassen?

Ich hätte auch Option 1 gewählt ;) und zusätzlich passe ich die Kommentare an um zu sehen, hier ist noch Handlungsbedarf aber deine Tests laufen erstmal durch.

HomeAutoUser · 2019-07-23T17:15:14Z

@sidey79
etwas unpassend zum Thema aber dennoch die Frage an dich zum Verständnis.

Was passiert wenn ich in die JSON Datei Daten eingebe als Ergebnis wenn ich das model manuell richtig gesetzt habe im Modul SD_UT Bsp.

Bisherigen Daten:
(das model wurde nocht nicht gesetzt, da es der Zustand nach dem Empfang ist, bevor der User selbst definieren muss)

{"name":"Roto TX-nM-HCS", "id":"88", "data": [
    {
      "dmsg":"P88#9451E57890EAFEF24", "comment":"encoded", "user":"bruen985",
      "internals": {"DEF":"F7F5709", "NAME":"SD_Keeloq_F7F5709"},
      "readings": {"state":"Please change your model via attribut!", "button":"0100", "serial_receive":"F7F5709", "user_info":"Please input KeeLoq_NLF, MasterMSB and MasterLSB Key!", "user_modus":"only_limited"},
      "rmsg":"MS;P0=-16052;P1=363;P2=-437;P3=-4001;P4=-829;P5=755;D=131452521452145252521452145252521414141452521452145214141414525252145252145252525214141452145214521414141414141452141414145252145252101212121212121212121212;CP=1;SP=3;R=51;O;m1;"
    }
  ]
},
{"name":"Waeco MA650-TX", "id":"88", "data": [
    {
      "dmsg":"P88#55D6D6EFCD9422044", "comment":"encoded", "user":"elektron-bbs",
      "internals": {"DEF":"04429B3", "NAME":"SD_Keeloq_04429B3"},
      "readings": {"state":"Please change your model via attribut!", "button":"0010", "serial_receive":"04429B3", "user_info":"Please input KeeLoq_NLF, MasterMSB and MasterLSB Key!", "user_modus":"only_limited"},
      "rmsg":"MS;P1=-425;P2=348;P3=-3925;P4=748;P5=-816;P6=-15724;D=234125412541254125252541254125254125254125412525412525254125252525252541412525412525414125412541414141254141412541414141414125414141262121212121212121212121;CP=2;SP=3;R=12;O;m1;"
    }
  ]
},

Korrekte Daten, nach dem definieren des Models vom User manuell um die Auswertung richtig zu erhalten:

{"name":"Roto TX-nM-HCS", "id":"88", "data": [
    {
      "dmsg":"P88#9451E57890EAFEF24", "comment":"encoded, button up", "user":"bruen985",
      "internals": {"DEF":"F7F5709", "NAME":"SD_Keeloq_F7F5709"},
      "readings": {"state":"receive", "batteryState":"ok", "button":"up", "repeat_message":"yes", "serial_receive":"F7F5709", "user_info":"Please input KeeLoq_NLF, MasterMSB and MasterLSB Key!", "user_modus":"only_limited"},
      "rmsg":"MS;P0=-16052;P1=363;P2=-437;P3=-4001;P4=-829;P5=755;D=131452521452145252521452145252521414141452521452145214141414525252145252145252525214141452145214521414141414141452141414145252145252101212121212121212121212;CP=1;SP=3;R=51;O;m1;"
    }
  ]
},
{"name":"Waeco MA650-TX", "id":"88", "data": [
    {
      "dmsg":"P88#55D6D6EFCD9422044", "comment":"encoded, button blue", "user":"elektron-bbs",
      "internals": {"DEF":"04429B3", "NAME":"SD_Keeloq_04429B3"},
      "readings": {"state":"receive", "batteryState":"ok", "button":"blue", "repeat_message":"yes", "serial_receive":"04429B3", "user_info":"Please input KeeLoq_NLF, MasterMSB and MasterLSB Key!", "user_modus":"only_limited"},
      "rmsg":"MS;P1=-425;P2=348;P3=-3925;P4=748;P5=-816;P6=-15724;D=234125412541254125252541254125254125254125412525412525254125252525252541412525412525414125412541414141254141412541414141414125414141262121212121212121212121;CP=2;SP=3;R=12;O;m1;"
    }
  ]
},

BEEINFLUSST das deine Tests, das diese fehl schlagen oder prüfst du nur die

"internals": {"DEF":"F7F5709", "NAME":"SD_Keeloq_F7F5709"},
"dmsg":"P88#55D6D6EFCD9422044",
ob diese mit der
"rmsg":"MS;P1=-425;P2=348;P3=-3925;P4=748;P5=-816;P6=-15724;D=234125412541254125252541254125254125254125412525412525254125252525252541412525412525414125412541414141254141412541414141414125414141262121212121212121212121;CP=2;SP=3;R=12;O;m1;"

gleich bleiben?

Nicht das ich mit unserer Genauigkeit deine Test´s erstmal fehl schlagen lassen ;-)

sidey79 · 2019-07-23T21:53:34Z

@HomeAutoUser
Danke dieser Nachfrage.

Im Moment läuft nur ein Basistest der das Ergebnis von DMSG verifiziert.
Selbst die Wiederholungen lassen sich derzeit nicht testen.
Somit kannst Du mit Änderungen an den readings oder den interals noch nichts kaputt machen.

Die Auswertung der Daten zu testen, würde die Qualität der Module allerdings noch verbessern und das sollten wir auch angehen.
So wie ich den Fall jetzt verstehe, würde diese Änderung dazu führen, dass die Sollwerte nicht anhand der Testdaten erreicht werden, da eine Änderung der angelegten Definition notwendig wäre.

Wäre folgendes Vorstellbar?

Der Testdatensatz wie er bislang vorliegt bleibt erhalten.
Es wird ein 2. Testdatensatz angelegt, der auf Basis des gesetztes Modelles die Sollwerte darstellt.
Zusätzlich wird der notwendige Perlcode in einer Bezeichnung hinterlegt die vor dem Test ausgeführt wird.

Ich hab jetzt noch keinen exakten Plan, woher man weiss, wann man das ganze aufrufen soll, aber vielleicht findet sich da ja noch was.

HomeAutoUser · 2019-07-23T22:43:17Z

Im Moment läuft nur ein Basistest der das Ergebnis von DMSG verifiziert.
Selbst die Wiederholungen lassen sich derzeit nicht testen.
Somit kannst Du mit Änderungen an den readings oder den interals noch nichts kaputt machen.

Da bin ich ja beruhigt ;-) und weis den Stand wie es derzeit abläuft.

So wie ich den Fall jetzt verstehe, würde diese Änderung dazu führen, dass die Sollwerte nicht anhand der Testdaten erreicht werden, da eine Änderung der angelegten Definition notwendig wäre.

Das ist richtig. Betreffs dem SD_UT Modul, so wird beim ersten anlegen wie folgt belegt ist
DEF | unknown

Erst nach einem manuellen auswählen des Modelles und erneutem Empfang wäre es dann so belegte
DEF | Buttons_five E

Alles ist von der selben DMSG bzw. selben RAWMSG. Der User muss nur bei 80% der Modelle selbst auswählen. Bei den anderen 20% wird das Modell direkt angelegt mit dem dazugehörigen DEF. Da würde es ja nicht stören. (eine automatische Modellzuordnung ist nur da vorgesehen wo auch eine Prüfung integriert ist in Form von einer CRC)

Wäre folgendes Vorstellbar?
Der Testdatensatz wie er bislang vorliegt bleibt erhalten.
Es wird ein 2. Testdatensatz angelegt, der auf Basis des gesetztes Modelles die Sollwerte darstellt.
Zusätzlich wird der notwendige Perlcode in einer Bezeichnung hinterlegt die vor dem Test ausgeführt wird.

Ich könnte mir nur das so vorstrellen, das im Comment Feld Bsp "model:Trabi" drin steht. Sowas in der Art?

Was meinst du mit PerlCode in einer Bezeichnung?

Prinzipiell wenn wir es "doppelt" eintragen geht es. Die "Mehrarbeit" führt dazu, das wir alle Fälle abdecken.

RAWMSG ohne modelauswahl automatisch
RAWMSG mit manuellen gesetzen model

sidey79 · 2019-07-23T22:47:50Z

Was meinst du mit PerlCode in einer Bezeichnung?

Der Test selbst weiss ja nicht, was genau gemacht werden soll, damit der Test durchläuft. Also könnte man in den Testdaten den Code hinterlegen, der das Modell setzt.
Der Test würde dann einfach den Code ausführen und anschließend die Ergebnisse verifizieren

HomeAutoUser · 2019-07-24T17:38:46Z

Hallo @sidey79,
ich habe mir das Ganze heute nochmal durch den Kopf gehen lassen und auch erörtert mal mit Anderen.
Das beste für den optimalen Kompromiss wird sein, das wir anstatt, so wie du es gestern vorgeschlagen hast, 2 Datensätze (einmal ohne Model und einmal mit manuell zugewiesenem Model) auf Dauer nicht praktikabel seien wird.

Wenn wir nur 1 Datensatz nutzen und diesen mit dem passenden Model versehen, so sollte es ausreichen. Alle Einträge wo kein Modelhinweis drin ist, werden normal behandelt und alle wo ein Modelverweis drin steht, dort musst du in den Tests das Attribut setzen auf den Wert. So benötigen wir die Mehrdaten (den Datensatz wo noch kein Modell ausgewählt wird nicht zwangsläufig)

Wie wir das Model verankern, ob im Comment oder noch eine Rubrik hinzufügen welche dem Attribut Model enspricht müsste man mal überlegen. Ich stelle mir das bei den Tests so vor, das diese den Modelnamen auslesen und du dann diesen setzen lassen kannst. (DAFÜR blicke ich aber zu wenig durch was man da machen muss) Gern möchte ich den Aufwand natürlich nicht unnötig "aufblähen" weil dann kommt irgendwann der Zeitpunkt wo man auch nachlässig wird.

sidey79 · 2019-07-24T20:57:17Z

Wenn wir nur 1 Datensatz nutzen und diesen mit dem passenden Model versehen, so sollte es ausreichen.

Kommt darauf an, was getetet werden soll.
Im Idealfall wird jede Codezeile getestet.
Wenn wir nun das Modell manuell setzen, dann wird vermutlich der Teil vom Autocreate nicht getestet ob er denn funktioniert.

Wie wir das Model verankern, ob im Comment oder noch eine Rubrik hinzufügen welche dem Attribut Model enspricht müsste man mal überlegen.

Im Kommentar ist so etwas immer unschön. Kommentare sind freitext und ungeeignet um eine Entscheidung zu treffen.

Ich stelle mir das bei den Tests so vor, das diese den Modelnamen auslesen und du dann diesen setzen lassen kannst.

Ich stelle mir das ja eher so vor, dass der Code, der für den Test ausgeführt werden muss, in den Testdaten hinterlegt ist.
Da es sich hier auch um besondere Anforderungen handelt wäre es vermutlich auch ratsam pro Modul einen Testfall zu entwickeln. Darin lassen sich die Besonderheiten dann gezielter handhaben.
Was meinst Du?

HomeAutoUser · 2019-07-24T21:30:23Z

Ich denke deine Denkweise zu verstehen bzw. was du auch als Zweck dahinter siehst.
Momentan sehe ich noch den Aufwand im Vordergrund, da ich nicht abschätzen kann wieviel man dann den anderen Entwicklern und Unterstützern zumutet.

1 . FrageZeichen im Kopf

Ich stelle mir das ja eher so vor, dass der Code, der für den Test ausgeführt werden muss, in den Testdaten hinterlegt ist.

Wieviel Code steckt dahinter?

2 . FrageZeichen im Kopf
Wer pflegt die Tests und erstellt diese immer? Bedenke bitte, die Tests sind auch für mich und die anderen erneut Neuland ;-)
3 . FrageZeichen im Kopf
Wie würde ein Satz aussehen wie du dir es vorstellst?

Wollen wir hier Tests auf Module entwickeln oder wollen wir die Funktion des Projektes SIGNALduino testen und erweitern? Ungern möchte ich zuweit abdriften.

sidey79 · 2019-07-26T10:47:28Z

Zu der 1. Frage:

Ich habe den genauen Syntax jetzt nicht nachgesehen aber soweit ich das verstanden habe, müsste ein Attribut gesetzt werden.
Das geht wie folgt:

CommandAttr(undef,"attr $defName model XYZ");

$defName wird vermutlich dem Ersteller der Testdaten bekannt sein.

Frage 2:

Ja, ich verstehe. Den Test pflegt hoffentlich derjenige, der am Code etwas anpasst.
Wenn solche besonderen Fällen abzudecken sind, dann liegt es leider schon in der Modul Implementierung, dass der Test etwas komplexer ausfällt.
Der Test simuliert an dieser Stelle ja die Benutzerinteraktion.

Zu 3.:

Das kann ich vom Handy leider nicht darstellen.

Denkbar wäre so etwas wie
"Pretest": "sub { CommandAttr(undef,"attr $defName model XYZ"); }"

Grundsätzlich ist es aber auch richtig, dass ein Test des SIGNALduino Modules ein anderer als ein Test eines Modules ist.

HomeAutoUser · 2019-07-26T13:55:54Z

Dann lass uns das beleuchten wenn du wieder einen PC zur Hand hast.

Ich habe als ersten notwendigen Schritt mal eingebaut, das das JSON den Bereich attributes erhält was momentan mit dem Modell gefüllt wird, wenn es existent ist.

Vielleicht gibt es einen Weg, das man den Code zum setzen des Attributes nicht in die JSON schreibt weil das wird unübersichtlich.

Wenn wir davon ausgehen, das das Commander zum setzen des Attributs gleich bleibt und auch der Preset Code, kannst du diese nicht verankern außerhalb der JSON Datei?

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Seit Anpassung der WH3080 Daten kommt es zu einem Fehler #17

Seit Anpassung der WH3080 Daten kommt es zu einem Fehler #17

sidey79 commented Jul 2, 2019

sidey79 commented Jul 3, 2019

HomeAutoUser commented Jul 3, 2019

sidey79 commented Jul 3, 2019

HomeAutoUser commented Jul 4, 2019

sidey79 commented Jul 4, 2019

HomeAutoUser commented Jul 4, 2019

sidey79 commented Jul 4, 2019

HomeAutoUser commented Jul 4, 2019

sidey79 commented Jul 4, 2019

sidey79 commented Jul 6, 2019

sidey79 commented Jul 7, 2019

HomeAutoUser commented Jul 8, 2019

HomeAutoUser commented Jul 23, 2019

sidey79 commented Jul 23, 2019

HomeAutoUser commented Jul 23, 2019

sidey79 commented Jul 23, 2019

HomeAutoUser commented Jul 24, 2019

sidey79 commented Jul 24, 2019

HomeAutoUser commented Jul 24, 2019

sidey79 commented Jul 26, 2019

HomeAutoUser commented Jul 26, 2019

Seit Anpassung der WH3080 Daten kommt es zu einem Fehler #17

Seit Anpassung der WH3080 Daten kommt es zu einem Fehler #17

Comments

sidey79 commented Jul 2, 2019

sidey79 commented Jul 3, 2019

HomeAutoUser commented Jul 3, 2019

sidey79 commented Jul 3, 2019

HomeAutoUser commented Jul 4, 2019

sidey79 commented Jul 4, 2019

HomeAutoUser commented Jul 4, 2019

sidey79 commented Jul 4, 2019

HomeAutoUser commented Jul 4, 2019

sidey79 commented Jul 4, 2019

sidey79 commented Jul 6, 2019

sidey79 commented Jul 7, 2019

HomeAutoUser commented Jul 8, 2019

HomeAutoUser commented Jul 23, 2019

sidey79 commented Jul 23, 2019

HomeAutoUser commented Jul 23, 2019

sidey79 commented Jul 23, 2019

HomeAutoUser commented Jul 24, 2019

sidey79 commented Jul 24, 2019

HomeAutoUser commented Jul 24, 2019

sidey79 commented Jul 26, 2019

HomeAutoUser commented Jul 26, 2019