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.

[carlos]

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

Hubert

[KölnSolar]

Auch ich bin für eine strikte Trennung durch eindeutige Benennung der Module.
Macht vieles klarer. Auch nach Jahren...
Grüße Markus

[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....)

[Ralf9]

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!

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.

[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]

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!

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.

Tendenziell 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?

[Ralf9]

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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)) {

Was 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.

Wäre es nicht möglich, das Modul zu einer Art Stub zu machen,

das sagt mir nichts

[rudolfkoenig]

Code Auswählen Erweitern

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]

Code Auswählen Erweitern

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.

Schwieriger als es jetzt gerade ist, kann es aber fast nicht mehr werden 

[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

[Ralf9]

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

[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.

[Sidey]

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.

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

[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 
 

[Sidey]

Hallo 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?

... Auch gefallen mir die Einstellungsmöglichkeiten bei seiner Version besser.

Welche Einstellmöglichkeiten fehlen deiner Ansicht nach dem SIGNALDuino?


Grüße Sidey

[Ralf9]

Kann 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

[rob]

Mit dem Status Quo hatte ich nie wirklich Probleme. Für beide Varianten bekam ich stets super Unterstützung  . 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.

Ralf, 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.

[Ralf9]

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.

Code Auswählen Erweitern

define sduino SIGNALduinoAdv /dev/serial/by-id/usb...
versionmodul v3.5.0-ralf_...
versionprotoL v3.5.0-ralf_...

Code Auswählen Erweitern

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:

- 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

Code Auswählen Erweitern

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

[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

Mit 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

[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...