Signalduino vs. Signalduino

[romakrau]

Hallo zusammen,
ich benutze derzeit ein ESP8266 mit der Signalduino Software von RFD-FHEM/SIGNALduino. Dies ist in meinem Fall eine stabile Version zur Nutzung von LaCrosse Sendern.

Code Auswählen Erweitern

version V 3.5.0-dev+20210808 SIGNALESP cc1101 (chip CC1101) - compiled at Feb 2 2022 07:54:34
versionProtocols 1.50
versionmodul 3.5.5+20230516
Ich möchte gerne eine Deckenventilator Protokoll-ID 127 in FHEM einbinden und benötige hierzu offensichtlich die Version von Ralf9. Da ich die beiden Version aufgrund der Namensgleichheit nicht parallel in FHEM benutze kann hätte ich gerne eine Tip wie man das Problem lösen kann. 

Gruß Roman

[romakrau]

Sorry, sehe gerade das der Deckenventilator von elektron.bbs in RFD-FHEM/SIGNALduino eingebunden wurde.

Der Namenskonflikt in den beiden Signalduino varianten besteht weiterhin.

[frober]

Der Namenskonflikt in den beiden Signalduino varianten besteht weiterhin.

Verstehe ich nicht...du kannst doch jedem Signalduino beim define einen anderen Namen geben.
Oder nachträglich umbenennen.
Im Device legst du dann mit

Code Auswählen Erweitern

attr IODev <NAME Signalduino> den Richtigen fest.

[romakrau]

Leider ist bei der Defination der Modulname anzugeben und das Modul lautet in beiden Fällen 00_SIGNALduino.pm.

[frober]

Zitat aus Comref:

Es ist möglich, mehr als ein Gerät anzuschließen, um beispielsweise besseren Empfang zu erhalten. FHEM wird doppelte Nachrichten herausfiltern. Mehr dazu im dem global Abschnitt unter dem Attribut dupTimeout

[Steigerbalett]

Ich möchte das Thema auch mal aufgreifen. 
Mittlerweile kann man ja eigentlich von zwei parallellaufenden Projekten sprechen. Beide sind weit verbreitet und haben jeweils ihre "Anhängerschaft". Eine gleichzeitige Nutzung ist aktuell nicht möglich. Ich habe auf der Suche nach einem funktionierenden Decoder für ein Signal diverse Versuche unternommen und dabei auch immer mal wieder von der Version von Sidey zur Version von Ralf9 gewechselt. Das ist immer ein größerer Aufwand, da man die Module tauschen muss und die Signalduino Firmware ja mittlerweile auch nicht mehr kompatibel ist. Für mich wäre eine gleichzeitige Nutzung bei der Fehlersuche extrem von Vorteil gewesen.
Was wäre nötig um beide Versionen gleichzeitig in FHEM betreiben zu können?
Das Modul von Sidey ist ja sozusagen das Ursprungsmodul, das von Ralf ein Fork. Könnte man z.B. hergehen und alle Module von Ralf (die einen identischen Namen haben) mit einem _r oder einem _ADV am Ende versehen und das in allen Modulen so referenzieren. Dann alles zusammen in Repository packen und in FHEM reinladen (Aktuell ziehe ich das aus vier verschiedenen Repos ins FHEM).
Könnten die beiden Versionen dann friedlich in FHEM nebeneinader her existieren?

Für den ESP32 gibt's von meiner SIGNALduinoAdv Firmware die Version V 4.2.2

Nimm die originale, die läuft bei mir auf einem ESP32: Du kannst diesen Stand mal versuchen, der wird auch demnächst releases

[ph1959de]

Ich habe in den letzten Wochen auch mit den Projekten von Ralf9 und Sidey zu tun gehabt und festgestellt, mit wie vielen eigentlich unnötigen Problemen man dabei zu kämpfen hat. Daher begrüße ich die Kommentare und Anregungen von Steigerbalett ausdrücklich.

Wäre es eventuell auch möglich, mit einem einzelnen SIGNALduino (FHEM Modul) die Funktionalität der beiden aktuellen Module abzudecken? Ließen sich die Unterschiede in (Unter-?)Module auslagern und die Funktionalität abhängig machen von der Firmware, die auf dem *duino (Hardware) installiert ist?

Falls das nicht geht, sollte aber auf jeden Fall die von Steigerbalett angeregte Umbenennung des Moduls von Ralf9 (bzw. beider Module, wenn nötig) durchgeführt werden. Damit könnten dann (hoffe ich) Devices für beide Module in einer FHEM Installation koexistieren und die Problematik beim Update würde entfallen.

Zudem würde sich der gesamte Komplex dann einfacher und eindeutiger dokumentieren lassen.

[Ralf9]

Nach meinem Verständnis werden nach Umbenennung des 00_signalduino Moduls die sduino Definitionen nicht mehr funktionieren.
Wenn das Modul z.b umbenannt würde in 00_SduinoAdv.pm dann müsste die sduino Def geändert werden in
define sduino SduinoAdv ...

Bei slowrf sollten sich das Modul vom mir und das von sidey eigentlich gleich verhalten.
Mit einem kleinen Patch in der Firmware von sidey würde diese auch bei FSK mit meinem Modul funktionieren.

Ich mache gerade ein paar Tage Urlaub in den Bergen, wenn ich wieder zuhause bin schreibe ich etwas mehr darüber

[Ralf9]

Eine zusammenlegung der 00_signalduino Module ist nicht machbar, dazu sind sie zu verschieden.
Das 00_signalduino Modul von Sidey ist inzwischen für mich zu komplex geworden. Es gibt dort im Ordner t für fast jede Routine eine Testroutine, das ist extrem komplex und aufwändig.
Dazu kommt noch, daß dort nur Protokolle übernommen werden, die auch mit der firmware von Sidey funktionieren.

Slowrf (ASK/OOK)
Bei Slowrf sollten sich die 00_signalduino Module gleich verhalten. Die Protokolldefinitionen sind fast alle gleich. Bei ein paar Protokollen habe ich optimierungen für nicht optimalem Empfang vorgenommen.
Es funktioniert auch die firmware von sidey mit meinem 00_signalduino Modul.

Meine firmware funktioniert mit dem 00_signalduino Modul von sidey nur mit Einschränkungen, da es bei den Parse Routinen sehr scharfe regex gibt:
https://forum.fhem.de/index.php?topic=58397.msg1201448#msg1201448

xFSK
Bei xFSK sind die 00_signalduino Module und die firmware nicht kompatibel.
Bei meiner firmware wird bei den MN-Nachrichten eine Nummerierung der verschiedenen rfmodes angehängt, z.B. N=7 bei Bresser.
Die rfmodes werden mit "set rfmode" mit dem CW Befehl übertragen.
Bei der firmware von sidey gibts keine Nummerierung der verschiedenen rfmodes. Mit dem Attribut rfmode werden die cc1101 Register einzeln übertragen.

Damit die firmware von Sidey auch bei xFSK mit meinem 00_signalduino Modul funktioniert ist ein kleiner Patch notwendig:
Dazu muß bei der Datei "cc1101.cpp" in der Routine "cc1101::getRxFifo()"
vor "MSG_PRINT(F(";R="));"
das eingefügt werden:

Code Auswählen Erweitern

uint8_t n = EEPROM.read(0x3D);
if (n > 0 && n < 40) {
MSG_PRINT(F(";N="));
MSG_PRINT(n);
}Z.B beim rfmode Bresser kann dann mit "set raw W3D07" das N=7 übertragen werden.

und bei der Datei "commands.h" die Routine getConfig wie folgt ändern:

Code Auswählen Erweitern

inline void getConfig()
{
MSG_PRINT(FPSTR(TXT_MS)); MSG_PRINT(FPSTR(TXT_EQ));
MSG_PRINT(musterDec.MSenabled, DEC);
MSG_PRINT(FPSTR(TXT_FSEP)); MSG_PRINT(FPSTR(TXT_MU)); MSG_PRINT(FPSTR(TXT_EQ));
MSG_PRINT(musterDec.MUenabled, DEC);
MSG_PRINT(FPSTR(TXT_FSEP)); MSG_PRINT(FPSTR(TXT_MC)); MSG_PRINT(FPSTR(TXT_EQ));
MSG_PRINT(musterDec.MCenabled, DEC);
#ifdef CMP_CC1101
if (cc1101::ccmode != 3) { // ASK/OOK = 3 (default)
MSG_PRINT(F(";xFSK"));
uint8_t n = EEPROM.read(0x3D);
if (n > 0 && n < 40) {
MSG_PRINT(F(";N="));
MSG_PRINT(n);
}
}
#endif
MSG_PRINT(F(";Mred="));
MSG_PRINTLN(musterDec.MredEnabled, DEC);
}
Ich habe versucht damit die firmware für den ESP8266 mit der Arduino IDE zu kompilieren, mir ist es aber nicht gelungen, ich habe beim kompilieren sehr viele Fehlermeldungen bekommen.
Kann mir jemand die firmware für den ESP8266 mit diesen Änderungen kompilieren?

Gruß Ralf

[Ralf9]

Mit platformio konnte ich die firmware kompilieren.
In der platformio.ini habe ich "lib_deps = https://github.com/tzapu/WiFiManager" ergänzt.
In der wifi-config.h und signalesp.h habe ich das #include "ArduinoJson.h" auskommentiert.
So habe ich mir das kopieren der Dateien vom WiFiManager und ArduinoJson erspart.

Nun habe ich die notwendigen cc1101 Register für den rfmode "DP100_WH51_WH57_433__B16_N16_17241" übertragen.
Mit "set raw W3D10" habe die konfig für N=16 übertragen.

Ein get "config" ergab dann

Code Auswählen Erweitern

config: MS=1;MU=1;MC=1;xFSK;N=16;Mred=1
Im log stand dann u.a.

Code Auswählen Erweitern

2023.08.29 16:37:54.586 4: sduinoE/msg READ: MN;D=510104C40C7F03005300000002FD2042;N=16;R=47;
2023.08.29 16:37:54.586 4: sduinoE Parse_MN: Found 2-FSK Protocol id 107 length 32 -> WH51 DP100
Die Version der firmware in der Anlage ist
V 3.5.1+20230125 SIGNALESP cc1101 (chip CC110 ...) - compiled at Aug 29 2023 15:28:33

Gruß Ralf

[Steigerbalett]

Eine zusammenlegung der 00_signalduino Module ist nicht machbar, dazu sind sie zu verschieden.

Hallo Ralf,
genau das meine ich.
Ich plädiere eher für eine komplette Entkopplung von Sideys Modul.

• Sidey: SIGNALduino
• Ralf9: SIGNALduinoAdv

Für mich sind das mittlerweile zwei verschiedene Module, auch mit unterschiedlicher Firmware(-unterstützung).
Wenn Dein Modul (SIGNALduino_Adv) mit all seinen Elementen umbenannt ist, kann man dann doch beide Module gleichzeitig nutzen, oder?
Du hast ja auch noch weiter Änderungen vorgenommen (10_IT.pm, 10_KOPP_FC.pm, 14_CUL_TCM97001.pm, 14_SD_WS.pm, 36_PCA301.pm) - auch da würde ich der einfachheithalber immer _Adv ranhängen: (10_IT_Adv.pm, ...). Ich weiß nicht welche anderen Abhängigkeiten noch bestehen... Dann alle Module per Github update add in FHEM laden und fertig (Bzw. wenn es genügend Bedarf gibt evtl. sogar direkt über das FHEM Repo ...)?
Wäre so ein Vorgehen möglich?
Wäre dies sehr schwer umzusetzen?
Oder liege ich komplett falsch und Du möchtest das gar nicht als eigenständiges Modul sehen?

[Ralf9]

Durch das Umbenennen des 00_SIGNALduino Moduls z.B. in 00_SIGNALduino_Adv, würden dann alle sduino devices die momentan mein 00_SIGNALduino verwenden, das 00_SIGNALduino von sidey verwenden und FSK würde dann nicht mehr funktionieren.
Die sduino devices müssten dann gelöscht und mit "define sduinoname SIGNALduino_Adv dev..." wieder eingerichtet werden. 

Meine Anpassungen der 10_IT.pm und 14_CUL_TCM97001.pm Module sind im SVN
Wenn z.B. das 14_SD_WS.pm in 14_SD_WS_Adv.pm umbenannt würde, müssten alle devices die das SD_WS_Adv Modul verwenden sollen gelöscht werden und als "define name SD_WS_Adv ..." wieder eingerichtet werden.

[Steigerbalett]

Die sduino devices müssten dann gelöscht und mit "define sduinoname SIGNALduino_Adv dev..." wieder eingerichtet werden. 

Das wäre für mich völlig in Ordnung und wäre kein Hinderungsgrund. Das macht man ja nur einmal und dann passt wieder alles, oder?

[Ralf9]

Das Problem dabei ist, außer Dir gibts auch noch viele andere die mein 00_SIGNALduino Modul verwenden.
Jeder der ein update auf das neue umbenannte 00_SIGNALduino Modul machen würde, müsste dann auch alle sduino devices löschen und wieder neu einrichten.
Jemand der dann ein update macht und nicht beachtet, daß er dann die sduino devices löschen und wieder neu einrichten muss, hat dann einen nicht mehr richtig funktionierenden sduino, das möchte ich vermeiden.

Bis jetzt hat sich außer Dir und ph1959de noch niemand dazu geäußert.

[tndx]

Moin,

ich würde das auch unterstützen. Würde m.M.n. auch den Einstieg einfacher machen, wenn klar getrennt ist; angefangen bei den git-Repositories, über Wiki-Seiten bis hin zu den Modulnamen. @Ralf, schau dir auch die Likes unter den Posts weiter oben an, da sind noch ein paar Unterstützer dieser Idee.