Signalduino vs. Signalduino

Begonnen von romakrau, 13 Juli 2023, 08:39:44

Vorheriges Thema - Nächstes Thema

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.

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

#2

Zitat von: romakrau am 13 Juli 2023, 08:54:16Der 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
attr IODev <NAME Signalduino> den Richtigen fest.
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

romakrau

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

frober

Zitat aus Comref:

ZitatEs 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
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

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?

Zitat von: Ralf9 am 24 Januar 2018, 20:04:44Für den ESP32 gibt's von meiner SIGNALduinoAdv Firmware die Version V 4.2.2
Zitat von: Sidey am 18 Juni 2023, 10:10:15Nimm 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.

Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"

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
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

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:
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:
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
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

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
config: MS=1;MU=1;MC=1;xFSK;N=16;Mred=1
Im log stand dann u.a.
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

FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Steigerbalett

Zitat von: Ralf9 am 29 August 2023, 00:37:47Eine 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.
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Steigerbalett

Zitat von: Ralf9 am 30 August 2023, 22:41:15Die 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.
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

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.

carlos

Wenn es tatsächlich nicht möglich ist beides zusammen zu nehmen, würde ich das auch unterstützen.
Gruß

Hubert
FHEM svn auf Intel NUC mit proxmox,1 UDOO, 3 Raspberry Pi, signalduino, nanoCUL, div. Homematic Komponenten, toom Baumarkt Funksteckdosen, einige sonoffs, hue, shelly

KölnSolar

Auch ich bin für eine strikte Trennung durch eindeutige Benennung der Module.
Macht vieles klarer. Auch nach Jahren...
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Beta-User

Prinzipiell macht mir der support-Aufwand für eine eventuelle Umstellung echt Sorge! Im Moment bin ich eher nicht überzeugt, dass sich eine "Doppler-Aktion" wirklich lohnt und fürchte sehr viele verärgerte User!

Andererseits muss man sich (nach meinem eventuell falschen Verständnis) heute (pro FHEM-Instanz) entscheiden, welche Fassung man denn gerne hätte. Je nach Umfeld kann das auch ein Problem sein...

Tendenziell wäre es super, wenn wir wieder auf einen einheitlichen Weg kämen mit "best of both worlds"! (Ist mir klar, dass das für beide maintainer der größere Aufwand wäre, aber m.E. wäre das besser, als in der Übergangsphase die User komplett zu verwirren....)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ralf9

#18
ZitatPrinzipiell macht mir der support-Aufwand für eine eventuelle Umstellung echt Sorge! Im Moment bin ich eher nicht überzeugt, dass sich eine "Doppler-Aktion" wirklich lohnt und fürchte sehr viele verärgerte User!
Ja, das denke ich auch, auch wenn ich dann Hinweise und Warnungen dazuschreibe, werden dann einige auf das neue umbenannte Modul updaten, ohne die Hinweise zu beachten, und dann hier schreiben, daß der sduino nicht mehr funktioniert.

Es wird dann auch kein einfacher wechsel zwischen den 00_SIGNALduino Modulen möglich sein.

Bei slowrf (ASK/OOK) sollte eigentlich kein Parallelbetrieb beider Versionen notwendig sein.
Mit meinem 00_SIGNALduino Modul können auch sduinos mit der firmware von sidey verwendet werden.
Wenn sidey beim 00_SIGNALduino Modul bei den parse Routinen die regex entschärfen würde, könnten auch sduinos mit meiner firmware verwendet werden.

Bei FSK ist ein parallelbetrieb nur mit recht großem Aufwand machbar.
Eine Umbenennung von meinem 14_SD_WS Modul ist nicht praktikabel, es müssten dann alle SD_WS devices gelöscht und wieder neu eingerichtet werden.
Bei Bedarf könnte ich mein 14_SD_WS Modul so anpassen und ergänzen, daß es auch bei FSK mit dem 00_SIGNALduino Modul von sidey verwendet werden kann.

FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

rudolfkoenig

Wenn eine komplette Zusammenführung nur mit unvertretbaren Aufwand verbunden ist, dann bin ich auch fuer eine Umbenennung.
Was Vergleichbares gibt es auch mit CUL vs. CUL_TS.

Steigerbalett

Zitat von: Beta-User am 05 September 2023, 10:51:04Prinzipiell macht mir der support-Aufwand für eine eventuelle Umstellung echt Sorge! Im Moment bin ich eher nicht überzeugt, dass sich eine "Doppler-Aktion" wirklich lohnt und fürchte sehr viele verärgerte User!
Was spricht dagegen SIGNALduinoADV ein neues Github Repositry zu spendieren und damit die Supportproblematik verägerter User zu umgehen?
Dann muss man aktiv die Updatequelle umstellen und sollte daher dann auch wissen, dass man seine Devices einmal neu anlernen muss.



Zitat von: Beta-User am 05 September 2023, 10:51:04Tendenziell wäre es super, wenn wir wieder auf einen einheitlichen Weg kämen mit "best of both worlds"!
Ja, aber das sieht für mich nach noch deutlich mehr Aufwand für die Maintainer aus als die Supportproblematik.

ph1959de

Wäre es nicht möglich, das Modul zu einer Art Stub zu machen, der dann "das richtige" Modul (oder entsprechende Routinen innerhalb des Moduls) aufruft? Wäre es damit möglich, anhand des bestehenden Devices / der "angebundenen" Firmware die "richtigen Entscheidungen" zu treffen? Mit der Problematik, dass ein eigentlich "RalfDuino" Device mit dem "SideyDuino" Modul (und umgekehrt) angesprochen wird, müssten die beiden Module doch bereits umgehen können?

In meiner (zu naiven?) Vorstellung müsste sich doch damit der Umstieg für die Benutzer transparent gestalten lassen, es müssen keine Devices migriert werden und ein Parallelbetrieb der beiden Typen sollte mögliche sein?
Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"

Ralf9

#22
Bei einer Umbenennung in 00_SIGNALduinoADV.pm müssen dann als ersten Schritt erst mal einige Client Module angepasst werden.
Auf die schnelle habe ich die folgenden Module gefunden:

10_IT.pm
if ($io->{TYPE} ne "SIGNALduino") {
in
if ($io->{TYPE} ne "SIGNALduino" && $io->{TYPE} ne "SIGNALduinoADV") {

10_SOMFY.pm
if ($ioType eq "SIGNALduino") {
in
if ($ioType eq "SIGNALduino" || $ioType eq "SIGNALduinoADV") {

if ($ioType ne "SIGNALduino") {
in
if ($ioType ne "SIGNALduino" && $ioType ne "SIGNALduinoADV") {

14_CUL_TCM97001.pm
if (($readedModel eq "Eurochron" || (hex($a[6]) == 0xF && $readedModel eq "Unknown" && $hash->{TYPE} ne "SIGNALduino") && $syncBit[1] < 5000)) {
in
if (($readedModel eq "Eurochron" || (hex($a[6]) == 0xF && $readedModel eq "Unknown" && $hash->{TYPE} ne "SIGNALduino" && $hash->{TYPE} ne "SIGNALduinoADV") && $syncBit[1] < 5000)) {

ZitatWas spricht dagegen SIGNALduinoADV ein neues Github Repositry zu spendieren und damit die Supportproblematik verägerter User zu umgehen?
Ja das wäre wahrscheinlich am praktikabelsten
Dann wäre es in github kein fork mehr.
Ich müsste dann in das neue Github Repositry SIGNALduinoADV z.B. eine Version von 2018 commiten und dann die commits per cherry pick rüber holen.

ZitatWäre es nicht möglich, das Modul zu einer Art Stub zu machen,
das sagt mir nichts



FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

rudolfkoenig

Wäre es nicht möglich, das Modul zu einer Art Stub zu machen,Das ist im Prinzip moeglich (analog zu Interface oder abstrakte Klasse), allerdings bleibt das Problem des Supports: man uebersieht leicht, welche Implementierung gerade verwendet wird.
Auch die "statische" Dokumentation wird dadurch umstaendlich.

ph1959de

Zitat von: rudolfkoenig am 07 September 2023, 12:34:29Wäre es nicht möglich, das Modul zu einer Art Stub zu machen,Das ist im Prinzip moeglich (analog zu Interface oder abstrakte Klasse), allerdings bleibt das Problem des Supports: man uebersieht leicht, welche Implementierung gerade verwendet wird.
Auch die "statische" Dokumentation wird dadurch umstaendlich.
Schwieriger als es jetzt gerade ist, kann es aber fast nicht mehr werden  :-[
Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"

Ralf9

Wenn nichts dagegen spricht habe ich folgendes vor:
- neues repository SIGNALduinoADV
- importieren des repository 14_SD_WS, damit das 14_SD_WS und das 00_SIGNALduinoADV im selben repository sind
- eine Version von 2018 des 00_SIGNALduino commiten und dann die commits per cherry pick rüber holen.
  beim cherry pick werde ich wahrscheinlich Hilfe benötigen
- das 14_SD_WS Modul so ändern damit es auch bei FSK mit dem 00_SIGNALduino Modul von Sidey funktioniert
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Ralf9

#26
Ich habe inzwischen ein neues Repro angelegt
https://github.com/Ralf9/SIGNALduinoADV_FHEM
und das bisherige repro importiert und dann per merge rebase das dev nach main gebracht.

Nun möchte ich die 23 commits
https://github.com/Ralf9/14_SD_WS/commits/main
rüber holen.

Kann ich dies auch mit dem github desktop machen?
https://dev.to/jmalvarez/how-to-cherry-pick-a-commit-from-another-repository-4pf1
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Sidey

Also meine 5ct zum Thema:

Man kann prinzipiell alles wieder in ein Projekt zusammenführen und die Lizenzverstöße beenden.

Das ist aber ziemlich viel Aufwand, da die Veränderungen einzeln überführt werden müssten.
Welche und wie viele das sind weiss ja nur Ralf9.
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Sidey

Zitat von: Steigerbalett am 21 August 2023, 22:15:13Ich 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.

Da Du ja beide intensiv getestet hast.
Hast Du mal ein Beispiel, was die Ursprungsversion nicht empfängt? Mir ist da nichts bekannt, was die Ursprungsfirmware nicht empfangen kann. Das einzige, was ich mir vorstellen könnte, ist dass es Protokolldefinition gibt, die nicht für beide Varianten existieren.
Die sind aber beim Ursprungsprojekt schon seit langem vom Modul entkoppelt und unabhängig vom IO Modul.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Steigerbalett

Hallo Sidey,
ich bin damals z.B. wegen der besseren Somfy-Unterstützung zur Version von Ralf gewechselt... Auch gefallen mir die Einstellungsmöglichkeiten bei seiner Version besser.

Ralf9

Bei dem 00_SIGNALDuino Modul von Sidey würden schon kleine Änderungen bei den recht scharfen regex in den Parse Routinen ausreichen, damit auch die mit meiner firmware empfangenen raw-Nachrichten verarbeitet werden.

Bei den rexex werden z.Zt. auch am Ende der raw-Nachrichten Sachen geprüft, die zum Verarbeiten gar nicht benötigt werden:
- Bei den MS-Nachrichten braucht was hinter CP=.. und SP=.. kommt nicht geprüft werden
- Bei den MU-Nachrichten braucht was hinter D=.. kommt nicht geprüft werden
- Bei den MC-Nachrichten braucht was hinter C=.. und L=.. kommt nicht geprüft werden
- Bei den MN-Nachrichten braucht was hinter D=.. kommt nicht geprüft werden

Wenn das "get raw" wieder eingebaut würde, wäre das senden von raw-Befehlen wieder komfortabler.
Momentan ist es recht umständlich, wenn man die Rückmeldungen der firmware sehen will. Vor dem "set raw" muß man erst das sduino verbose auf 4 erhöhen damit man die Rückmeldungen im log sehen kann.

Bei MC-Nachrichten kann es Unterschiede geben, da es bei Manchester in der firmware und beim 00_Signalduino Modul unterschiede gibt.

Gruß Ralf 
 
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Sidey

Zitat von: Steigerbalett am 10 September 2023, 12:21:45Hallo Sidey,
ich bin damals z.B. wegen der besseren Somfy-Unterstützung zur Version von Ralf gewechselt

Damals? Was genau ist da besser, kannst Du das näher beschreiben?

Zitat von: Steigerbalett am 10 September 2023, 12:21:45... Auch gefallen mir die Einstellungsmöglichkeiten bei seiner Version besser.

Welche Einstellmöglichkeiten fehlen deiner Ansicht nach dem SIGNALDuino?


Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Ralf9

Zitat von: Ralf9 am 08 September 2023, 18:34:17Kann ich dies auch mit dem github desktop machen?
https://dev.to/jmalvarez/how-to-cherry-pick-a-commit-from-another-repository-4pf1
Hat sich erledigt, das cherry pick geht mit github desktop recht komfortabel
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

rob

Mit dem Status Quo hatte ich nie wirklich Probleme. Für beide Varianten bekam ich stets super Unterstützung  8) . Hier stehen imho im Grunde zwei Ansagen im Raum: nicht beides gleichzeitig nutzbar und unnötige Probleme.

Für mich bleibt unklar, welche Probleme mit der Trennung konkret gelöst werden sollen. Was sind diese Probleme? Geht es allein um Doku? Gibt es evtl. andere/ bessere Lösungen als den Split?
Es gibt wohl keine Lösung ohne andere Nachteile. Und wenn unterm Strich nur "Probleme" mit neuen "Problemen" getauscht werden, war der Aufwand/ Wirbel schnell umsonst. Bsp: Wohin melde ich dann künftig neue Geräte/ Protokolle usw.?

Zu "nicht gleichzeitig nutzbar" fällt mir auf, dass einige Leute zwei oder mehr FHEM-Instanzen nutzen. Wenn ich partout mehrere S'Duinos mit inhaltlich versch. aber gleichlautenden Modulen haben muss, würde ich es damit versuchen.

Ralf, Du hast eh schon losgelegt. Wie würde sich der Übergang aus Deiner Sicht konkret für User darstellen?
Gedanke: Die betroffenen User müssten ja meist "https://raw.githubusercontent.com/Ralf9/RFFHEM/..." unter update list stehen haben. Ließe sich ggf. eine (einmalige??) Log-Meldung in FHEM generieren, wenn das der Fall ist + das neue Repo genommen werden muss, aber noch Devices vom Typ "SIGNALduino" vorhanden sind?
Bspw.: "The Repo for your SIGNALduino(s) is outdated, please change your update source to the new one. For further information read this: https://blablabla  ..."
Der Trigger wäre dann wohl update all(?).

Viele Grüße
rob

Ralf9

Ja die Trennung durch Umbenennung von meinem 00_SIGNALDuino Modul hat Vorteile und auch Nachteile. Es ist dann kein einfacher wechsel zwischen den 00_SIGNALDuino Modulen mehr möglich.

ZitatRalf, Du hast eh schon losgelegt. Wie würde sich der Übergang aus Deiner Sicht konkret für User darstellen?
Für das neue umbenannte 00_SIGNALDuino Modul gibts dann ein neues repro
https://github.com/Ralf9/SIGNALduinoADV_FHEM
Dann muss man aktiv die Updatequelle umstellen und sollte daher dann auch wissen, dass man seine sduino Devices ändern muss.
In diesem repro ist dann auch meine Version des 14_SD_WS Moduls. Ich bin gerade dabei das 14_SD_WS Modul so anzupassen, daß es auch bei FSK mit dem 00_SIGNALDuino Modul von Sidey verwendet werden kann.
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Ralf9

#35
Ich habe nun das 00_SIGNALduino.pm in 00_SIGNALduinoAdv.pm umbenannt. Es war im Code recht viel umzubenennen. Ich habe es noch nicht komplett getestet.
Dadurch hat sich auch der TYPE in SIGNALduinoAdv geändert
z.B.
define sduino SIGNALduinoAdv /dev/serial/by-id/usb...
versionmodul v3.5.0-ralf_...
versionprotoL v3.5.0-ralf_...
update all https://raw.githubusercontent.com/Ralf9/SIGNALduinoAdv_FHEM/master/controls_ralf9_signalduino.txt
https://github.com/Ralf9/SIGNALduinoAdv_FHEM/tree/master/FHEM
https://github.com/Ralf9/SIGNALduinoAdv_FHEM/commit/c47119b528fb59c89a83a2e8eddd6ea248efa95c

FSK funktioniert nur mit meiner Version des 14_SD_WS Moduls. Ich habe Anpassungen vorgenommen, damit es auch bei FSK mit dem 00_SIGNALduino Modul von Sidey funktioniert:
Zitat- dmsg mit den ID 117 werden nach 207 geändert und die ersten 4 Zeichen entfernt, damit es kompatibel zum Modul von Sidey ist
- ID 115: wenn die dmsg vom 00_SIGNALduino Modul von Sidey kommt, werden die ersten 4 Zeichen entfernt
- ID 211: nach ID 125 geändert damit es kompatibel zum Modul von Sidey ist
- ID 213: nach ID 126 geändert damit es kompatibel zum Modul von Sidey ist

Bei den folgenden Modulen sind für die 00_SIGNALduinoAdv.pm Anpassungen notwendig:

10_IT
14_CUL_TCM97001
10_SOMFY

Sind im SVN (FHEM update)

36_PCA301
https://github.com/Ralf9/36_PCA301.pm
update all https://raw.githubusercontent.com/Ralf9/36_PCA301.pm/master/controls_ralf9_36_PCA301.txt
10_KOPP_FC
Siehe Anlage

14_SD_Keeloq
todo

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

rob

Hallo Ralf.

Vielen Dank für die Umstellung + Info. Hab es bei mir jetzt auch nachgezogen. Einfach per defmod geht es zwar nicht - löschen und neu anlegen ist aber auch kein Drama :)

Beste Grüße
rob

weini

Hallo Ralf!

Vielen Dank dir!

Ich habe die Umstellung vor einigen Tagen vollzogen und es läuft bisher alles problemlos.
Mein 868 MHz SignalDuino läuft jetzt mit dem Adv-Modul und deiner FW und mein 433 MHz SignalDuino mit der Standard-FW und dem "normalen" Modul.

Noch eine Frage: Da meine Zähler erneuert wurden und jetzt "funken" würde ich gerne WM-Bus Signale Empfangen. Charmant wäre, wenn ich das mit meinem 868 MHz SignalDuino machen könnte.
  • Dafür braucht es ja die 4.2 FW, richtig? Gibt es die auch schon für den nanoC1011 SignalDuino oder nur für Maple/ESP?
  • Falls ich das mit meinem nanoC1011 nutzen kann, dann würde ich alle 6h auf den WM-Bus Modus schalten und danach wieder zurück auf LaCrosse. Mache ich mir damit auf die Dauer das Flash-RAM kaputt oder sollte das funktionieren?

VG,
weini
[/list]

Ralf9

Hallo weini,

nein, beim Signalduino funktioniert WMBUS nur mit dem Maple und ESP32
Für den nanoC1011 gibts eine culw firmware
https://forum.fhem.de/index.php?topic=24517.msg915481#msg915481

Das optimierte wechseln der aktiven EEPROM Bank, bei dem nicht ins EEPROM (flash) geschrieben wird, funktioniert nicht beim WMBUS
ZitatMit nachgestelltem f optimiertes wechseln der aktiven EEPROM Bank (nur bei FSK, ccmode 1-4, nur ab Firmware V3.3.5 und V4.2.2)

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

weini

Vielen Dank dir für die schnelle Antwort.
Dann muss ich überlegen wie ich das anders baue. Ich hätte zwar noch einen 868 MHz CUL "übrig", aber keine freien USB Anschlüsse mehr am Raspi.
Also entweder noch mehr Kabelverhau mit einem Hub oder vielleicht doch ein Umstieg auf den Maple...

elektron-bbs

Da du Firmware und Module von Ralf9 verwendest, kann ich nicht direkt weiter helfen. Wahrscheinlich müsstest du mal ein Update durchführen. In der aktuellen Version von Ralf9 sehe ich den Inkbird.

Besprochen wurde das Protokoll hier: https://forum.fhem.de/index.php/topic,128945.0.html
Intel(R) Atom(TM) CPU N270 mit 2 SIGNALduino nanoCC1101 + ESPEasy 2x serial server SIGNALduino nanoCC1101, Raspberry Pi 2 mit 2 CUL Stackable CC1101, Raspberry Pi 3 mit SIGNALduino radino + nano328 + 2 x SIGNAL-ESP CC1101 + 2 x rf_Gateway

OliS.

Sorry, ich hatte meinen Post gelöscht, bevor ich Deine Antwort gesehen habe. Ich hatte es in der Zwischenzeit mit Sideys Version und einer anderen Hardware probiert. Damit konnte ich den Sensor dann empfangen.
Leider reicht das Funksignal des Thermometers nicht bis in den Keller (wo mein Server steht). Deshalb werde ich mal schauen, ob ich mir einen SignalESP baue.

Lieben Dank trotzdem schon mal für die Unterstützung.
LG Oli
FHEM in Debian VM auf DS720+, HMLAN und HMUARTLGW, RFXTRX, Conbee II, Homebridge, Alexa
Geräte: Homematic, Tradfri, Shelly, IT, ESA2000, VU+, Denon-AVR, Sonos, Fritz!Box, Harmony Hub, IP-Cams, Roborock, Automower

Ralf9

Nicht so ungeduldig, an einem Tag wie heute wo viele draußen unterwegs sind, kann es etwas länger dauern.
Im Sommer kann es bei schönen Wetter auch mal länger als einen Tag dauern bis eine Antwort kommt.

Ich habs mirs mal angeschaut.
In der Protokolliste sieht man bei der ID 123 "modulation=2-FSK"
https://ralf9.github.io/SD_Device_Proto.html

Standardmässig ist SlowRF (ASK/OOK) aktiv, bei xFSK muss ein anderer rfmode gewählt werden.
Bei Sideys Version wird der rfmode über ein Attribut gewählt.
Bei meiner Version mit "set sduino rfmode" oder "set sduino rfmodeTesting"
Bei dem Inkbird ist es rfmodeTesting, da noch rückmeldungen fehlen und es noch nicht zu Ende entwickelt wurde. Es kann noch sein, daß beim Batteriewechsel noch nicht alles passt.

Bei meiner Version sieht es so aus:
set sduino rfmodeTesting Inkbird_433__B18_N14_FSKIm reading rfmode steht dann: "Inkbird_433__B18_N14_FSK => ok,N=14,ccmode=1"

Ein "get sduino ccconf" ergibt:
ccconf: freq:433.920MHz bWidth:101KHz rAmpl:33dB sens:8dB (DataRate:9992.60Baud)
Modulation:2-FSK (SYNC_MODE:16/16 sync) DEVIATN:34.912kHz

Gruß Ralf

FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

OliS.

Mit Ungeduld hatte das tatsächlich gar nichts zu tun. Ich hatte nur nach Lektüre der ganzen anderen Threads zu dem Thema das Gefühl, dass meine Frage in diesem Thread gar nicht richtig platziert gewesen ist. Als Neueinsteiger in Sachen SignalDuino ist braucht man etwas, um hinter die Unterschiede zwischen dem "offiziellen" Zweig und Deinem Fork zu kommen.
Ich erwarte hier wirklich von niemandem eine sofortige Antwort. Schon gar nicht, da ich als Nichtentwickler selbst ja kaum etwas beisteuern kann. Von daher weiß ich Eure Arbeit wirklich sehr zu schätzen.

Ich habe mich jetzt weiter eingelesen und mittlerweile empfange ich das Thermometer zuverlässig mit einem SignalESP. Die Reichweite ist allerdings immer noch unterirdisch, was aber vermutlich an dem ungeeigneten 868MHz Empfangsmodul liegt.

Lieben Dank noch mal für die Antworten.
Oli
FHEM in Debian VM auf DS720+, HMLAN und HMUARTLGW, RFXTRX, Conbee II, Homebridge, Alexa
Geräte: Homematic, Tradfri, Shelly, IT, ESA2000, VU+, Denon-AVR, Sonos, Fritz!Box, Harmony Hub, IP-Cams, Roborock, Automower