Signalduino Entwicklung

[Sidey]

Hallo Sidey,

ja habe ich. Und der letzet Stand als Cresta hat funktioniert.

Jörg

Hi Jörg,

In Zeile 1830 müsste stehen Hideki protocol converted...

In deinem Log taucht aber Cresta protocol converted...

Das lässt vermuten, dass nicht das aktuelle 00_Signalduino aus dem Cresta Branch bei dir läuft.

Grüße Sidey

[pejonp]

....
In Zeile 1830 müsste stehen Hideki protocol converted...
In deinem Log taucht aber Cresta protocol converted...
...

Hallo Sidey,

ich habe jetzt folgendes gemacht. FHEM gestopt. Alle Cresta, Hideki und Signalduino Dateien gelöscht. FHEM gestartet. Fehler weil die Dateien nicht da sind (siehe Log).
in FHEM :
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-cresta/controls_signalduino.txt
gemacht. FHEM-Server noch einmal neu gestartet. Keine Veränderung, ausser das jetzt im Log Hideki steht.
Hast du einen Bresser,Hama oder Sensor da zum testen. Wenn nicht, schicke mir mal eine PM mit der Adresse und ich lasse dir einen zukommen, damit auch bei späteren Ändernungen nicht immer die Sensoren rausfliegen.

Jörg

[Sidey]

Hallo Jörg,

Hast du einen Bresser,Hama oder Sensor da zum testen. Wenn nicht, schicke mir mal eine PM mit der Adresse und ich lasse dir einen zukommen, damit auch bei späteren Ändernungen nicht immer die Sensoren rausfliegen.

Nein ich habe derzeit keinen. Ich teste immer mit euren Daten
So richtige Regressionstest von allem mache ich leider nicht. Da müsste ich mir mal was überlegen. Das ginge sogar über FHEM Befehle.

Nunja, ich habe gestern getestet. Wieso ich den Fehler nicht gefunden habe, wundert mich ja selbst.
Ausnahmsweise bin ich auch mal nicht Schuldig. Mir ist zwar noch nicht klar, wieso das Problem erst jetzt aufgetreten ist, aber ich konnte den Fehler finden und einen Workaround einbauen.

Eigentlich liegt das Problem im 41_Oregon Modul. Die Daten passen auch auf das Match Regex für dieses Modul.
Das Modul versucht den Sonsor zu identifizieren, gibt aber nicht undef sondern einen Text aus.
Damit wird kein anderes Modul, in dem Fall das Hideki, mit den Daten versorgt.

Ich werde einen Patch für das Oregon Modul vorschlagen, damit es aber wieder funktioniert, habe ich die Reihenfolge des Hideki Modules verändert. Es wird jetzt einfach vor dem Oregon Modul aufgerufen.

Grüße Sidey

[Ralf9]

Eigentlich liegt das Problem im 41_Oregon Modul. Die Daten passen auch auf das Match Regex für dieses Modul.
Das Modul versucht den Sonsor zu identifizieren, gibt aber nicht undef sondern einen Text aus.

Hallo Sidey,

seltsam, ich hatte beim Match Regex noch nie Probleme mit dem Oregon Modul. Die Bresser- und Hama Sensoren haben immer problemlos funktioniert.
Kann das evtl damit zusammenhängen, daß ich als Firmeware noch die 3.1.5 habe?

Ist eigentlich irgendwo definiert, daß die Hideki message mit "58" oder "50" beginnt?
Wenn sie z.B. mit "hi" beginnen würde, dürfte es beim Match Regex keine Probleme mit anderen Modulen geben.

Gruß Ralf

[Sidey]

Hi Ralf,

seltsam, ich hatte beim Match Regex noch nie Probleme mit dem Oregon Modul. Die Bresser- und Hama Sensoren haben immer problemlos funktioniert.

Ja, in den Modulen selbst ist es definiert, aber im IO Device kann man auch eine Matchlist pflegen:

Code Auswählen Erweitern


     "4:OREGON"            => "^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*",
     "3:Hideki" => "^[5][0|8]75[A-F0-9]+",


Im Modul kann man das etwas genauer machen wenn man möchte.

5875.. anfangen, passen in die Regex des Oregon Modules, obwohl es das j nicht auswerten kann.
Prinzipiell ist es nicht tragisch, aber es gibt sowas wie ein "alles ok" an die dispatch Funktion zurück.

Da jetzt etwas künstlich vorne an zu stellen, halte ich nicht für zielführend.
Setzt man HI davor und hat noch ein Modul das H vorne angestellt als Indikator verwendet hat man wieder nichts gewonnen. H gab es auch schon mal beim FHEMDuion, ob das noch wo verwendet wird weiss ich aktuell nicht. Zwangsläufig gehen einem aber schnell die Buchstaben aus.

Da fand ich es logisch die Länge + 0x75 als Indikator ob es eine Hideki Nachricht ist.

Grüße Sidey

[Ralf9]

Hallo Sidey,

Danke, nun ist es klar. Es gibt also Hideki Nachrichten mit einer Länge von 50 und 58.
Wenn die Nachricht in die Hideki Regex passt, dann wird die OREGON Regex gar nicht mehr geprüft.
Das passt dann so.

Gruß Ralf

[Sidey]

Hi Ralf,

Fast.
Wenn das hideki Modul einem Return wert der als int 1 gewertet wird zurück gibt, dann werden die Daten nicht an das Oregon Modul gegeben.

Soweit ich das einschätze, hat der Windmesser zwei Bytes mehr.
Es ist also wahrscheinlich,  dass andere Längen auch noch ein valides Hideki Signal sind.

Grüße Sidey

[Sidey]

Hallo allerseits,

Wollte mal ein kleines Update geben:

Dank des Anwenders Ellert , habe ich die Nachrichten Verarbeitung für MU Nachrichten über arbeitet.
Da waren unschöne Bugs enthalten.

Dabei bin ich auch auf einen Bug im der Firmware gestoßen,  der einen Absturz verursachen kann.

Leider wohl nicht der letzte.

Außerdem habe ich einige Signale in letzter Zeit definiert.
Viele davon werden noch nicht sauber dekodiert, das führt zu jeder Menge Dekodierungs Versuchen und Meldungen im Log.

Keine Sorge. Ich werde das noch lösen, dass die Logmeldungen wieder reduziert werden.

Grüße Sidey

[Ralf9]

Wenn das hideki Modul einem Return wert der als int 1 gewertet wird zurück gibt, dann werden die Daten nicht an das Oregon Modul gegeben.

Ist dies der Returnwert vom {Match} oder vom {ParseFn}?

Gruß Ralf

[Sidey]

Parsefn

[RappaSan]

Hallo Sidey,

ich habe testweise mal FHEMduino gegen Signalduino ausgetauscht (siehe http://forum.fhem.de/index.php/topic,17196.msg336757.html#msg336757).
In der Tat: das Oregon-Device liefert wieder Daten. Muß also irgendwas im FHEMduino-Modul im Argen sein...
Auch werden deutlich mehr Geräte empfangen (wahrscheinlich die lieben Nachbarn).

Das Konzept der Signalbearbeitung finde ich super und wegweisend.

Leider klappt aber dort der IT/Elro Zweig besser als beim Signalduino. Dort klappt Senden und Empfang der Funksignale besser. Da ich meine Wohnzimmer/Gartenbeleuchtung mit diesen Elro-Funksteckdosen automatisiert habe, bin ich wieder erst einmal zurückgekehrt zu FHEMduino.
Für die Funksteckdosen wird bei Dir nach der Dekodierung das Modul 10_IT.pm benutzt. im FHEMduino ist es das Modul 14_FHEMduino_PT2262.pm oder?

Liegt es vielleicht an diesem Unterschied?

[Sidey]

Hi Rappsan,

Schön, dass Du es mal probiert hast.

Warum das mit den Steckdosen bei dir nicht funktioniert, kann ich nicht ohne ein paar Logs feststellen.

Ich hab auch ein paar Steckdosen,  da klappt die Erkennung genauso gut oder schlecht wie im Fhemduino.

Kannst Du mir mal die Logs mit Verbose 5 erstellen?

Grüße  Sidey

[pejonp]

..

Nein ich habe derzeit keinen ...

Nunja, ich habe o das Problem erst jetzt aufgetreten ist, aber ich konnte den Fehler finden und einen Workaround einbauen.

Eigentlich liegt das Problem im 41_Oregon, Modul.

Hallo sidey,
Mit dem hideki stehe ich irgendwie auf dem Schlauch . Auch wenn ich eine ältere Versions zurückspiele (cresta) werden keine Sensoren mehr angelegt. Im log wird alles erkannt aber irgendetwas an der weiter/Übergabe stimmt nicht. Die nachfolgemodule werden nicht angesprochen. Ich werde heute mal alle Einträge bis auf hideki rausnehmen, mal sehen was passiert. Oder gibt es eine andere Lösung ?

Jörg

[Hauswart]

Nur zur Info meine Elro Steckdosen funktionieren ohne Probleme  

[Sidey]

Hi Jörg,

Ich verstehe auch nicht, weshalb es da solche Probleme gibt.

Ist ja echt zum heulen, da ich es gestern auch noch getestet habe.

In welchem Zeitabständen kommen die Werte bei dir vom Sensor an?

Sidey