Hallo,
mit den Anpassungen die ich im 00_SIGNALduino.pm Modul
https://github.com/Ralf9/RFFHEM/blob/c69593f34a3116f4f5f8dce8ad18a51fbf1b0ebb/FHEM/00_SIGNALduino.pm#L4982
und in der SIGNALduino Firmware vorgenommen habe
https://forum.fhem.de/index.php/topic,106594.msg1004463.html#msg1004463
werden seit einiger Zeit mit dem SIGNALduino auch die PCA301 unterstützt.
Im Gegensatz zum Jeelink und LaCrosse Gateway werden in der SIGNALduino Firmware die empfangenen Daten nicht konvertiert sondern als raw-Daten zum 00_SIGNALduino.pm Modul übertragen.
Da die gesendeten Daten in der Firmware auch nicht konvertiert werden, sind einige Anpassungen und Erweiterungen im 36_PCA301 Modul erforderlich.
https://github.com/Ralf9/fhem-mirror/commit/442d6f3faa3029c48794faecd62d8de1f1fedad5
Ich habe ein SendRetry eingebaut, damit bei schlechten Empfangsbedingungen das Senden wiederholt wird.
Ich hab dafür 2 Konstanten eingefügt.
use constant {
PCA301_send_OnOffStatus_timeout => 2, # Wartezeit bis ein sendRetry gemacht wird
PCA301_send_max_cmdRetry => 4
};
Außerdem habe ich für das Pollen des Statusrequest das Attribut pollStatus (Pollintervall in Sekunden) hinzugefügt.
Die Anpassung funktioniert wahrscheinlich so nicht mehr richtig mit dem Jeelink und LaCrosse Gateway, da müssen noch ein paar Abfragen eingebaut werden.
Ist es möglich diese Anpassungen in die Version vom SVN zu übernehmen oder ist es besser, wenn ich für den Signalduino ein eigenes Modul mache (z.B. 14_SD_PCA301).
Gruß Ralf
Zitat von: Ralf9 am 14 Mai 2020, 00:12:39
Die Anpassung funktioniert wahrscheinlich so nicht mehr richtig mit dem Jeelink und LaCrosse Gateway, da müssen noch ein paar Abfragen eingebaut werden.
Ist es möglich diese Anpassungen in die Version vom SVN zu übernehmen oder ist es besser, wenn ich für den Signalduino ein eigenes Modul mache (z.B. 14_SD_PCA301).
Wenn es mit dem LaCrosseGateway nicht mehr funktioniert sollte man es so nicht übernehmen.
Hi Ralf,
erst nochmal danke, dass Du das umgesetzt hast.
Mir stellt sich die erste Frage zu
Zitatmit den Anpassungen die ich im 00_SIGNALduino.pm Modul
Wird die dann produktiv ? Zur Zeit nutze ich ja die 00_Signalduino aus Deinem Beitrag.
ZitatIm Gegensatz zum Jeelink und LaCrosse Gateway werden in der SIGNALduino Firmware die empfangenen Daten nicht konvertiert sondern als raw-Daten zum 00_SIGNALduino.pm Modul übertragen.
Die Thematik haben wir ja auch im 10_IT oder auch anderen ASK_OOK-Modulen, die mit dem CUL und dem S'duino laufen. Wie ist das denn dort gelöst, dass das Modul mit beiden Sticks funktioniert ?
ZitatAußerdem habe ich für das Pollen des Statusrequest das Attribut pollStatus (Pollintervall in Sekunden) hinzugefügt.
Das ließe sich zur Not ja auch über ein at realisieren(ich erinnere mich an die Diskussionen mit Andre, als ich das ähnlich für den CUL machen wollte).
Grüße Markus
Zitatmit den Anpassungen die ich im 00_SIGNALduino.pm Modul
siehe hier
https://forum.fhem.de/index.php/topic,106594.msg1047071.html#msg1047071
ZitatDie Thematik haben wir ja auch im 10_IT oder auch anderen ASK_OOK-Modulen, die mit dem CUL und dem S'duino laufen. Wie ist das denn dort gelöst, dass das Modul mit beiden Sticks funktioniert ?
Dort sind solche "if ($io->{TYPE} ne "SIGNALduino") {" Abfragen drin, falls meine Anpassungen auch ins SVN können,
kann ich diese Abfragen beim Pollen des Statusrequest und beim Sendretry einbauen.
Gruß Ralf
Zitatsiehe hier
Ich glaub ich habs verstanden. Irgendwie immer wieder kompliziert die S'duino-Welt. :-\
ZitatDort sind solche "if ($io->{TYPE} ne "SIGNALduino") {" Abfragen drin, falls meine Anpassungen auch ins SVN können,
Das klingt doch gut.
Dann ist dieser concern
ZitatDie Anpassung funktioniert wahrscheinlich so nicht mehr richtig mit dem Jeelink und LaCrosse Gateway, da müssen noch ein paar Abfragen eingebaut werden.
doch gelöst bzw. es müssten sich nur Tester(edit: Arthur_dent ist da sicher ein Kandidat) finden, die abschließend die Funktionsfähigkeit mit diesen IO-devices bestätigen, oder ? :-\
Zitat von: KölnSolar am 14 Mai 2020, 08:25:34
Dann ist dieser concern doch gelöst bzw. es müssten sich nur Tester(edit: Arthur_dent ist da sicher ein Kandidat) finden, die abschließend die Funktionsfähigkeit mit diesen IO-devices bestätigen, oder ? :-\
Wenn ihr wollt, kann ich es für das LGW testen, ob es damit noch funktioniert. Wenn das geht, sollte es auch für den JeeLink gehen.
Das 36_PCA301.pm gehört aber justme1968, ich kann (bzw. darf) also nur testen aber es nicht ins SVN packen.
Hier ist eine erste Testversion
https://github.com/Ralf9/36_PCA301.pm
Ich habe es nochmals überarbeitet und auch ein paar Dinge von perlcritic berücksichtigt.
Ich habe "if ($io->{TYPE} eq 'SIGNALduino'))" Abfragen eingebaut, damit es auch mit Jeelink und LaCrosse Gateway funktionieren müsste.
justme1968 liest Du hier mit?
Gruß Ralf
Hallo,
ich lese hier passive mit und muss zum einen Bedenken anmelden aber auch Respekt vor der Arbeit aussprechen.
Wenn man in ein Modul etwas integriert nach dem Schema,
"if ($io->{TYPE} eq 'SIGNALduino'))"
so sollte man sicher gehen, das auch die offizielle Version des SIGNALduino damit funktioniert. Alles andere bringt nur Streit, Diskussionen im Forum und zusätzliche Fragen.
Das würde nach meinen Gedanken dann folgermaßen aussehen.
Maintainer beider Module informieren für die Erweiterung und zusätzlich auch der Hinweis an allen Stellen, das es nur mit dieser einen Version funktioniert
Hier überall mehren sich die Informationen wo teilweise nicht die richtigen Marker gesetzt sind und bei einem Clone Projekt, welches sich so nennt wie das Orginal, ist ein Durcheinader vorprogrammiert.
??? Bitte das Thema bzw. die Themen hier im Forum richtig kennzeichnen. Wir laufen sonst Gefahr, das eigene aufgestellte Regel des Forums gebrochen werden. ::)
Da es hier auch um SVN Module geht, so verweise ich hierauf. (https://wiki.fhem.de/wiki/SVN_Nutzungsregeln)
Ich möchte hier keine Kritik üben. Es geht mir nur um Sachlichkeit und das wir Entwickler nicht einfach die Benutzer in die Irre führen. Zusätzlich kommen dann Fragen auf den Maintainer zu weil dieser nicht diese Funktion integriert hat oder NOCH nicht vollzogen hat. Nur wenn wir dies nach und nach zusammenführen, funktioniert alles weiterhin kompatibel.
Da mein angepasstes und erweitertes 36_PCA301 Modul z.Zt. nur mit meinen Firmware Versionen funktioniert, ist es wohl besser, wenn es nicht ins SVN kommt.
Ich werde es dann zusammen mit den entsprechenden Firmware Versionen anbieten, so wie es auch noansi mit seiner angepassten Cul Version macht.
Gruß Ralf