MAX und SIGNALduino?

Begonnen von Ralf9, 30 Oktober 2023, 22:38:14

Vorheriges Thema - Nächstes Thema

Wzut

@Ralf, das du die Beta Versionen genommen hast ist gut !
Das an 14_CUL-MAX einiges anzupassen ist war mir klar, mach mal ich übernehme wenn es läuft und spendiere ein zusätzliches Attribut zur Unterscheidung CUL oder Signalduino.
fakeWT und fakeFK Adressen musst du nicht extra ins EEPROM packen, die sind mit 111111 und 222222 schon immer fix, d.h. du kannst sie ruhig Hardcoden.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Ralf9

Kann es sein, dass in der 14_CUL-MAX noch bugs sind?

Wenn ich zum Fensterkontakt "set deassociate" mache, wird nichts gesendet. Ich habs auch mit einem nanocul mit der V 1.67 versucht.

Ich hab in der 14_CUL-MAX zum debuggen in der "sub SQH" ein paar log Ausgaben eingefügt:
...
    my ($packet, $pktIdx, $dst);

    for ($pktIdx = 0; $pktIdx < @{$hash->{sendQueue}}; $pktIdx ++) {
$packet = $hash->{sendQueue}[$pktIdx];

if ($responseToShutterContact) {
    # Find a packet to the ShutterContact in $responseToShutterContact
    # Aufruf Sonderfall
    last if ($packet->{dst} eq $responseToShutterContact);
}
else {
    Log3($name, 4, "$name, pktIdx=$pktIdx cmd=" . $packet->{cmd} . " type=" . $packet->{type} . " sent=" . $packet->{sent} . " We cannot sent packets to a ShutterContact directly");
    #We cannot sent packets to a ShutterContact directly, everything else is possible
    last if (($packet->{cmd} eq 'PairPong')
    || ($packet->{sent} != 0)
    || ($packet->{type} ne 'ShutterContact'));
        Log3($name, 4, "$name, after last if");
}
    }

    Log3($name, 4, "$name, pktIdx=$pktIdx");
    if ($pktIdx == @{$hash->{sendQueue}} && !$responseToShutterContact) {
Log3($name, 4, "$name, Send Queue packet for ShutterContact $packet->{dst_name} exists");
$timeout += 3;
InternalTimer($timeout, 'FHEM::CUL_MAX::SQH', $hash, 0);
#Log3 $hash, 5, $name.', Send Queue in not empty yet, next run in '.sprintf("%.1f",($timeout-gettimeofday())).' seconds';
return;
    }

Hier ist ein log Auszug von set_deassociate 01ce98:
2024.11.01 20:01:11.646 4: MAX_654321, send -> cmd:RemoveLinkPartner, msgcnt:1c, flags:00, Cmd2id:21, src:MAX_654321, dst:MAX_1f2021, gid:00, payload:01ce9803, cul:sduino
2024.11.01 20:01:11.646 5: MAX_654321, packet to SQH : 0e1c00216543211f20210001ce9803
2024.11.01 20:01:11.646 5: MAX_654321, Send Queue : 1 packet are in the queue
                           pktIdx=0 cmd=RemoveLinkPartner type=ShutterContact sent=0 We cannot sent packets to a ShutterContact directly
                           after last if
                           pktIdx=1
2024.11.01 20:01:11.646 4: MAX_654321, Send Queue packet for ShutterContact MAX_1f2021 exists
2024.11.01 20:01:14.648 5: MAX_654321, Send Queue : 1 packet are in the queue
2024.11.01 20:01:14.648 4: MAX_654321, Send Queue packet for ShutterContact MAX_1f2021 exists

und hier ist ein log Auszug von "set desiredTemperature 13.0" vom Wandthermostat:
2024.11.01 20:04:08.646 4: MAX_654321, send -> cmd:SetTemperature, msgcnt:53, flags:00, Cmd2id:40, src:MAX_654321, dst:MAX_01ce98, gid:00, payload:5a, cul:sduino
2024.11.01 20:04:08.646 5: MAX_654321, packet to SQH : 0b53004065432101ce98005a
2024.11.01 20:04:08.646 5: MAX_654321, Send Queue : 1 packet are in the queue
                           pktIdx=0 cmd=SetTemperature type=WallMountedThermostat sent=0 We cannot sent packets to a ShutterContact directly
                           pktIdx=0
2024.11.01 20:04:08.646 5: MAX_654321, Send Queue sduino -> needPreamble: 1, necessaryCredit: 110, credit10ms: sduino = 900, CMD_LAST_H: 0
2024.11.01 20:04:08.646 4: set sduino raw Zs0b53004065432101ce98005a
2024.11.01 20:04:08.646 4: MAX_654321, Send Queue packet send : Zs0b53004065432101ce98005a to MAX_01ce98 with sduino


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

Wzut

Zitat von: Ralf9 am 01 November 2024, 21:55:56Kann es sein, dass in der 14_CUL-MAX noch bugs sind?

Wenn ich zum Fensterkontakt "set deassociate" mache, wird nichts gesendet.
a. aber nicht, ich (und andere) nutzen es seit Jahren ohne Probleme.
b. Du kannst einem FK so direkt nichts senden! FKs spielen eine Sonderrolle, da sie normalweise im Sleep Mode sind. D.h. 14_CUL_MAX befüllt die SQH und wartet auf einen Moment wo der FK kurz wach ist um dann "ganz schnell" sein asso/deasso Telegramm loszwerden. Das geht aber leider sehr oft schief und ich vermute das über 90% der im Einsatz befindlichen FKs gar nicht mit einem HT/WT gepeered sind, sondern statt dessen Broadcast Telegramme verschicken ( Ziel 000000 ) D.h. das associte / deassociate an einen FK ist nicht wirklich wichtig, im Gegensatz zu einem HT oder WT.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Ralf9

Nun funktioniert das asso/deasso beim Fensterkontakt. Ich hatte es vorher so gemacht wie im Wiki beschrieben:
ZitatWährend Wand- und Heizkörperthermostat stets empfangsbereit sind, benötigt der Fensterkontakt zum "Wecken" einen Schaltvorgang des Reed-Relais (Fenster öffnen oder schließen). Den Anlern-Button auf der Rückseite zu drücken, wäre völlig falsch!
Es funktioniert aber nur, wenn man den Anlern-Button drückt.
Wenn man weiß wie es funktioniert und auf was man achten muss, funktioniert es recht gut.

Ich hab auch mal den Heizkörperthermostat (firmware 1.6) getestet, aber passt noch nicht alles.
Ich kann zwar mit fhem den Heizkörperthermostat auf Auto stellen, aber mit der linken Taste am Heizkörper kann ich zwar von Auto nach Manu, aber nicht von Manu nach Auto wechseln.
Das Antennensymbol wird nicht angezeigt.
 
Ich hab auch ein asso/deasso fakeWT getestet.
Obwohl das deasso erfolgreich war, wurde der fakeWT nicht aus den peer Readings entfernt
MAX_Parse, MAX,1,AckRemoveLinkPartner,05943d,deassociate,111111Einige Readings:
.associatedWith MAX_111111
IODev           MAX_654321
PairedTo        654321
lastcmd         deassociate 111111
peerIDs         111111
peerList        MAX_111111
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

Wzut

@Ralf :
a. Wiki : Das ist nicht auf meinem Mist gewachsen und leider steht dort einiges was absolut falsch ist.
U.a. halt auch das Peering eines FK. Der Orinal ELV Cube bekommt das aber wirklich mit open/close hin, nicht mit einem Re-Pairing.

b. Wenn das HT nicht von man auf Auto wechselt fehlt eigentlich das Pairing mit der Zentrale. Dem widerspricht allerdings deine Aussage das es erfolgreich Kommandos von FHEM annimmt.
Um das zu überprüfen hilft nur ein verbose 5 am CUL_Max Device.

c. Putzen der Readings : Da werde ich in 10_MAX nochmal ran müssen. Dem Vorgang habe ich seinerzeit keine große Prio eingeräumt.

Vorschlag : Gib mir doch deine bisherige Firmware und das geänderte 14_CUL_MAX Modul und ich mache selbt ein paar Tests
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Ralf9

#35
Es gibt eine neue Version von den FHEM Modulen 00_SIGNALduinoAdv.pm und lib/signalduino_protocols.pm
versionmodul  v3.5.2-ralf_04.11.24
versionprotoL v3.5.2-ralf_04.11.24
update all https://raw.githubusercontent.com/Ralf9/SIGNALduinoAdv_FHEM/master/controls_ralf9_signalduino.txt
Bei der sduino Firmware gibts eine neue Version V 4.2.3-dev241104 SIGNALduinoAdv ...
Mit dem Maple Mini funktionierts mittlerweile recht gut (Firmware siehe Anlage). Bei Bedarf kann ich auch eine Firmware für den Maple Cul erstellen.
Beim ESP 32 funktioniert das Empfangen und Senden, das Autoacknowledge funktioniert noch nicht.
Evtl liegts am Timing des Autoacknowledge welches recht kritisch ist. Evtl ist es durch interrupts der ESP32 Firmware minimal länger als beim Maple.

Die Adresse für das Autoacknowledge wird nicht mehr automatisch mit Za zur Firmware übertragen.
Sie muss mit "set sduino raw Za.." (z.B. Za654321) zur sduino Firmware übertragen werden und wird im EEPROM gespeichert.
Mit dem raw Befehl Zg kann die Autoacknowledge Adresse abgefragt werden.

Bei dem 14_CUL_MAX.pm Modul (siehe Anlage) musste ich für den sduino einige Anpassungen vornehmen.

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

Zitat von: Ralf9 am 07 November 2024, 23:48:30Beim ESP 32 funktioniert das Empfangen und Senden, das Autoacknowledge funktioniert noch nicht.
Das Autoacknowledge funktioniert jetzt auch, die Ursache war vermutlich, dass beim ESP32 das übertragen der empfangenen Nachricht per WLAN zu FHEM minimal länger dauert als beim Maple Mini über USB oder LAN.
Ich habe es so gemacht, dass die empfangene Nachricht erst nach dem senden vom Autoacknowledge zu FHEM übertragen wird.
z0B1300026543211F20210000
MN;D=0B1306301F202165432100105283;N=15;r;
Das asso/deasso beim Fensterkontakt funktioniert beim ESP32 nicht, das ist zu zeitkritisch.
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

Wzut

Ich habe gestern Abend alles in meine Testumgebung gepackt und werde am WE mal einiges testen.
Deine Änderungen im 14_CUL_MAX habe ich bis jetzt nur auf die Schnelle überflogen - das meiste sollte verständlich sein. Bis auf .updateConfigWait ... wieso muss updateConfig "mit Gewalt" nach 20 Sekunden quasi nochmal aufgerufen  aufgerufen werden statt einfach nur wenn FHEM mit seinem Start durch ist ?

Zitat von: Ralf9Ich habe es so gemacht, dass die empfangene Nachricht erst nach dem senden vom Autoacknowledge zu FHEM übertragen wird.
D.h. wenn ich eine MaxId benutze die nicht zu meiner Installation passt kann ich den Sduino nicht als Scanner benutzen , bzw. ich sehe damit keine Telegramme die nicht direkt die Zentrale FHEM als Ziel haben wie etwa Telegramme zwischen einem HT und einem WT ? 


Zitat von: Ralf9Die Adresse für das Autoacknowledge wird nicht mehr automatisch mit Za zur Firmware übertragen.
Sie muss mit "set sduino raw Za.." (z.B. Za654321) zur sduino Firmware übertragen werden und wird im EEPROM gespeichert.
soll/kann ich im CUL_MAX erledigen, die ID ist ja bekannt und ob er User einen CUL oder Sduino als IO nutzt soll er eh in einem Attribut vorher selbst bestimmen.
Obwohl da fällt mir natürlich direkt IO Group ein - da wäre ja zum einen eine Mix Gruppe aus CUL-Sduino als auch eine reine Gruppe Duinos denkbar.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Ralf9

Zitat... wieso muss updateConfig "mit Gewalt" nach 20 Sekunden quasi nochmal aufgerufen  aufgerufen werden statt einfach nur wenn FHEM mit seinem Start durch ist ?
Wenn das updateConfig am Anfang über Notify global aufgerufen wird, ist der sduino noch nicht initialisiert, das kann bei LAN oder WLAN auch ca 10 sek dauern.
2024.11.09 10:35:31.318 3: MAX_654321, Notify global , INITIALIZED
2024.11.09 10:35:32.971 3: sduino/noMsg Parse: V 4.2.3-dev241104 SIGNALduinoAdv ...
2024.11.09 10:35:32.988 2: sduino: initialized. v3.5.2-ralf_04.11.24
2024.11.09 10:35:51.091 4: MAX_654321 updateConfig

2024.11.09 10:45:34.941 3: MAX_654321, Notify global , INITIALIZED
2024.11.09 10:45:35.009 3: sduinoE device opened
2024.11.09 10:45:48.034 3: sduinoE/noMsg Parse: V 4.2.3-dev241104 SIGNALduinoAdv LAN ...
2024.11.09 10:45:48.051 2: sduinoE: initialized. v3.5.2-ralf_04.11.24
2024.11.09 10:45:54.704 4: MAX_654321 updateConfig

2024.11.09 10:55:48.641 3: MAX_654321, Notify global , INITIALIZED
2024.11.09 10:55:48.722 3: sduinoE device opened
2024.11.09 10:55:51.863 3: sduinoE/noMsg Parse: V 4.2.3-dev241108 SIGNALduinoAdv ESP32 ...
2024.11.09 10:55:52.005 2: sduinoE: initialized. v3.5.2-ralf_04.11.24
2024.11.09 10:56:08.389 4: MAX_654321 updateConfig

ZitatD.h. wenn ich eine MaxId benutze die nicht zu meiner Installation passt kann ich den Sduino nicht als Scanner benutzen
Es werden alle Max Nachrichten empfangen und an FHEM übertragen. Vor dem ausgeben der empfangenen Nachricht wird auf Autoacknowledge geprüft und ggf ein Ack gesendet.

Ja das mit dem Za Befehl kann auch von CUL_MAX erledigt 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

Ralf9

Hier ist die "V 4.2.3-dev241111 SIGNALduinoAdv ESP32"
https://forum.fhem.de/index.php?topic=83273.msg1324774#msg1324774

Der rfmode für max ist unter "set sduino rfmodeTesting ..."

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

SalvadoreXXL

Muss ich alle Max-Geräte neu pairen? Komme vom Cube mit aculfw.

Ralf9

Das peering zwischen den Max Geräten müsste bleiben können.
Damit die Maxid vom sduino in die Max Geräte geschrieben werden können, müssen diese mit dem sduino gepairt werden.

Gibt es außer dem Factoryreset noch eine andere Möglichkeit bei einem Max Gerät das pairing wieder zu entfernen.

Ist es beim Wandthermostat normal, dass wenn er gepairt ist man mit einem langen druck auf die Mode Taste nicht mehr ins Menü kommt?
Dadurch kann ein Wandthermostat nicht mehr lokal am Gerät zurück gesetzt 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

Wzut

Zitat von: Ralf9 am 12 November 2024, 23:00:38Damit die Maxid vom sduino in die Max Geräte geschrieben werden können, müssen diese mit dem sduino gepairt werden.
HALT STOPP !!
Das ist genau die gleiche Falschaussage wie sie auch im Wiki zu finden ist und nur unnötige Arbeit und Frust für die User bedeutet.
Wenn ein MAX! Gerät einmal seine Zentrale (maxid) kennt (Pairing) dann vergisst es diese so schnell nicht mehr, egal ob der reine Hardware Funk Empfänger CUL, Cube oder SIGNALduino heisst !
Erst wenn diese ID gewechselt werden soll ( warum auch immer ) es es nötig einen Werksreset zu machen und danach das Gerät neu zu Pairen. Beim Wersreset gehen auch die associate (Peering) Informationen verloren.

Pairing  = Verbindung eines Gerätes mit der Zentrale
Peering  = Verbindung zweier MAX Geräte (HT-WT, HT-FK, WT-FK, HT-HT)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Wzut

Zitat von: Ralf9 am 12 November 2024, 23:00:38Gibt es außer dem Factoryreset noch eine andere Möglichkeit bei einem Max Gerät das pairing wieder zu entfernen.

Nein

Zitat von: Ralf9 am 12 November 2024, 23:00:38Ist es beim Wandthermostat normal, dass wenn er gepairt ist man mit einem langen druck auf die Mode Taste nicht mehr ins Menü kommt?
Dadurch kann ein Wandthermostat nicht mehr lokal am Gerät zurück gesetzt werden.
Wenn ein MAX Gerät Gepaired ist sind bestimmte Funktionen über die Tasten direkt nicht mehr möglich.
Ein Werksreset geht dann nur über FHEM oder wie in der ELV Anleitung beschrieben, durch Bat raus, 60 Sekunden warten, drei Tasten halten und Batterie neu einlegen. Bei HT und WT erscheint dann rES im Display.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Ralf9

Zitat von: Wzut am 13 November 2024, 09:14:43Wenn ein MAX Gerät Gepaired ist sind bestimmte Funktionen über die Tasten direkt nicht mehr möglich.
Ein Werksreset geht dann nur über FHEM oder wie in der ELV Anleitung beschrieben, durch Bat raus, 60 Sekunden warten, drei Tasten halten und Batterie neu einlegen. Bei HT und WT erscheint dann rES im Display.
Danke, hatte es in der Anleitung übersehen.

ZitatGibt es außer dem Factoryreset noch eine andere Möglichkeit bei einem Max Gerät das pairing wieder zu entfernen?
Funktioniert das nicht, wenn beim PairPong als source 000000 angegeben wird?

Zitat von: Wzut am 13 November 2024, 09:06:28Erst wenn diese ID gewechselt werden soll ( warum auch immer ) es es nötig einen Werksreset zu machen und danach das Gerät neu zu Pairen.
Wenn ich das richtig verstanden habe, muss jede Zentrale eine eigene MaxID haben, wenn man zum Testen bei einem Gerät auf eine andere Zentrale wechseln will, muss man dann bei diesem Max Gerät ein Werksreset machen.

Ich habe das mit der IO Group nicht verstanden, wird dies irgendwo erklärt?

Mir ist auch noch aufgefallen, dass beim Fensterkontakt beim PairPong ein Zs-Befehl verwendet wird, es sollte auch der fast Zf-Befehl reichen.

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