MAX und SIGNALduino?

[Wzut]

Eine IO Group ist etwas mehr als mehre Sendegeräte zu haben Ich hole mal etwas aus :
1. unterschiedliche Ids wird nicht funktionieren. Jedes gepairte MAX Device kennt die Adresse seines "Chefs" und nur auf diesen einen Chef hört er. Alles andere sind "Fremde" und die werden komplett ignoriert.

2. Der Sinn einer IO Group ist eine gute Funkabdeckung auf einer großen oder schwierigen Fläche wie z.B, ein komplettes Haus mit mehren Stockwerken. Hier ist es wichtig zu wissen welches IO Device optimal für jedes MAX Device ist. Beim reinen Empfang spielt das keine Rolle, hauptsache das Telegramm ist nicht zerstört. Hier ist auch egal ob eventuell das "schlechtere" Device zuerst in FHEM ist. FHEM hat ja die Eigenart vermeintlich doppelte Telegramme zu unterdrücken. D.h. das nächste Telegramm vom IO Device aus der IO Gruppe wird von FHEM automatisch verworfen und kommt nie bei 14_CUL_MAX an. Später beim Senden ist es aber wichtig zu wissen welches das "Beste" IO Device ist. Durch den leider dreistufigen Aufbau bei MAX ( 00_CUL -> 14_CUL_MAX -> 10_MAX ) hat das MAX Gerät am Ende dieser Kette keine Ahnung wer wie gut mit ihm spricht. Als Abhilfe hat Rudi mir damals eine Änderung in 00_CUL.pm eingebaut so das der CUL diese wichtige Info direkt in die Internals des MAX Device schreibt. Code aus 00_CUL.pm :

Code Auswählen Erweitern

if(exists($modules{MAX}{defptr}{$src}) && defined($rssi))
     $modules{MAX}{defptr}{$src}{helper}{io}{$name}->{time} = gettimeofday();
     $modules{MAX}{defptr}{$src}{helper}{io}{$name}->{rssi} = $rssi;
     $modules{MAX}{defptr}{$src}{helper}{io}{$name}->{raw} = $dmsg;
}

3. Senden mit der IO Group. Großes Vorbild war für mich die ccu bei Homematic mit ihrer IOList.
Den HM Komfort der automatischen Senderauswahl habe ich zwar leider nie erreicht, aber mit der direkten Info der RSSI Werte aus 00_CUL kann der User recht gut selbst entscheiden welches das optimale Sendedevice ist und dieses unter CULdevice eintragen. Unterstützt wird er dabei durch Meldungen im Log wenn die aktuele Empfangssituation sich verändert , Beispiel aus einem meiner Logs :

Code Auswählen Erweitern

024.11.23 10:55:31 3: 2_WT_Wohnzimmer, Maple1 has better average RSSI values than the current preferred CULdev !was auch stimmt wenn man sich die Readings in  2_WT_Wohnzimmer dazu anschaut :

Code Auswählen Erweitern

2024-11-23 12:15:52   CUL1st          Maple1 -78.5
2024-11-23 12:15:52   CUL2nd          Keller_CUL -85.2       

[Ralf9]

unterschiedliche Ids wird nicht funktionieren. Jedes gepairte MAX Device kennt die Adresse seines "Chefs" und nur auf diesen einen Chef hört er. Alles andere sind "Fremde" und die werden komplett ignoriert.

Warum sollte das nicht funktionieren? Ich habs bei mir getestet.

Ich habs damit getestet:

Code Auswählen Erweitern

sduino attr maxid 654321
CULnano attr maxid abc123

CUL_MAX attr IOgrp sduino,CULnano

WT ID=654321
attr CULdev sduino
attr autoselectCUL 0

Fensterkontakt ID=abc123
attr CULdev CULnano
attr autoselectCUL 0
Zum WT hat nur der sduino mit src=654321 gesendet und auch die Nachrichten vom WT per AutoAck quitiert.

Und zum Fensterkontakt nur der CULnano mit src=abc123
Das pairen und das asso/deasso mit dem Fensterkontakt hat auch funktioniert. Der CULnano hat die open/close Nachrichten vom Fensterkontakt per AutoAck quitiert.

[Wzut]

Wir reden aneinander vorbei, du hast zwei MAX Welten (654321 & abc123) geschaffen in der jedes deiner MAX Geräte einen festen Sendepartner hat. Das ist aber nicht der Sinn einer IOGrp, denn hier soll ja ein anderes Gerät quasi Hotbackup für das primäre Device sein. Wenn du den CUL ausschaltest hat der FK keinen Partner mehr und wenn du den SIGNALduino abschaltest hängt eigentlich das WT in der Luft, bzw es wird sich noch durchmogeln weil vermutlich deine 654321 ID noch am CULMAX Device hängt.   

[Ralf9]

Das hängt vom Anwendungsfall ab, mit der IOGrp sind auch verschiedene IDs möglich.
Gleiche IDs haben den Nachteil, dass bis zu 3 IODev gleichzeitig versuchen bestimmte empfangene Nachrichten per AutoAck zu quittieren.
Ich habe nicht getestet ob das immer sauber funktioniert.
Wenn das Hotbackup nicht benötigt wird, ist es besser verschiedene IDs zu verwenden.

[Ralf9]

Ich habe das

Code Auswählen Erweitern

$modules{MAX}{defptr}{$src}{helper}{io}{$name}->{time} = gettimeofday();
$modules{MAX}{defptr}{$src}{helper}{io}{$name}->{rssi} = $rssi;in das 00_SIGNALduinoAdv.pm Modul eingebaut (v3.5.2-ralf_23.11.24), damit wird bei mehreren IODev auch die rssi vom sduino angezeigt.

Mir ist auch aufgefallen, dass es im CUL_MAX Modul bei den "Send Queue packet for ShutterContact ... exists ..." Meldungen kein Timeout gibt.

In der Anlage ist auch eine neue Firmware für den Maple Cul und ESP32

[Wzut]

Mir ist auch aufgefallen, dass es im CUL_MAX Modul bei den "Send Queue packet for ShutterContact ... exists ..." Meldungen kein Timeout gibt.

ja, das war damals vom Autor der MAX Module auch so gewollt da die Leute ja Zeit brauchten an ihr Fenster zu laufen und es auf/zu zu machen bei einem associate. (um aber i.d.R. festtzustellen das die Flut der Meldungen nicht stopte, es gab damals unheimlich viele Beiträge zu dem Thema)
IMHO ist da aber bei der Original ELV Software auch so, d.h. die wartet auch ewig wenn man einen FK mit einem HT/WT verheiraten will und da klappt das auch wirklich mit dem Timing bei auf/zu.

[Ralf9]

Wenn hier das $timeout von 3 auf 0.5 verringert wird, dann funktioniert das asso/deasso auch beim Batterie raus und wieder einlegen.
Damit dann die log Meldung nicht alle 0.5 sek kommt, muss durch einen counter dafür gesorgt werden, dass die Meldung nur alle ca 5-10 Sek ausgegeben wird.
Da kann dann auch ein Timeout der Meldungen von ca 30-60 Min eingebaut werden.

Code Auswählen Erweitern

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

da klappt das auch wirklich mit dem Timing bei auf/zu

Dazu müsste das asso/deasso in die Firmware vom cul/sduino eingebaut werden, über fhem ist das zu langsam

[Wzut]

Den kleineren Timeout werd ich testen, das ausgeben der Log Meldungen seh ich etwas entspannter. Damals kamen diese Meldungen mit Level 3 statt heute 4.
Ja der Cube mit ELV Software hat in der Beziehung natürlich Vorteile, aber halt auch riesige Nachteile da dort kein Backup möglich war und bei einem Alzheimer Anfall der User jede Menge Spaß und Arbeit hatte.
Anyway - wenn der kleinere Timeout wirklich eine Lösung dieses uralten Problems bringt.

[SalvadoreXXL]

Bis auf den Fensterkontakt funktioniert alles gut. Bin mir nicht sicher, ob der Kontakt richtig gepairt wurde. Sehe das am Kontakt nicht:

Code Auswählen Erweitern

define MAX_04e0e0 MAX ShutterContact 04e0e0
attr MAX_04e0e0 model ShutterContact
attr MAX_04e0e0 room MAX
#   .count     -2
#   .sendToAddr -1
#   .sendToName
#   .timer     300
#   CFGFN     
#   DEF        ShutterContact 04e0e0
#   FUUID      67462787-f33f-ac49-1d9a-285bfeed408dbf57
#   IODev      cmax
#   LASTInputDev cmax
#   MSGCNT     34
#   NAME       MAX_04e0e0
#   NR         323
#   NTFY_ORDER 50-MAX_04e0e0
#   STATE      closed (rf error)
#   SVN        23517
#   TYPE       MAX
#   addr       04e0e0
#   cmax_MSGCNT 34
#   cmax_TIME  2024-11-26 21:12:47
#   devtype    4
#   eventCount 39
#   type       ShutterContact
#   .attraggr:
#   .attrminint:
#   READINGS:
#     2024-11-26 21:12:47   .lastact        1732651967.52975
#     2024-11-26 20:54:47   IODev           cmax
#     2024-11-26 21:11:33   PairedTo        654321
#     2024-11-26 21:12:47   RSSI            -82
#     2024-11-26 21:11:33   SerialNr        JEQ0511586
#     2024-11-26 21:12:47   battery         ok
#     2024-11-26 21:12:47   batteryState    ok
#     2024-11-26 21:11:34   error           Invalid command/argument  8110
#     2024-11-26 21:11:33   firmware        1.3
#     2024-11-26 21:11:33   msgcnt          5
#     2024-11-26 21:12:47   onoff           0
#     2024-11-26 21:12:47   rferror         1
#     2024-11-26 21:12:47   state           closed (rf error)
#     2024-11-26 21:11:33   testresult      15
#     2024-11-26 21:12:47   windowOpen      0
#   helper:
#     io:
#       SIGNALesp32:
#         rssi       -82
#         time       1732651967.5292
#
setstate MAX_04e0e0 closed (rf error)
setstate MAX_04e0e0 2024-11-26 21:12:47 .lastact 1732651967.52975
setstate MAX_04e0e0 2024-11-26 20:54:47 IODev cmax
setstate MAX_04e0e0 2024-11-26 21:11:33 PairedTo 654321
setstate MAX_04e0e0 2024-11-26 21:12:47 RSSI -82
setstate MAX_04e0e0 2024-11-26 21:11:33 SerialNr JEQ0511586
setstate MAX_04e0e0 2024-11-26 21:12:47 battery ok
setstate MAX_04e0e0 2024-11-26 21:12:47 batteryState ok
setstate MAX_04e0e0 2024-11-26 21:11:34 error Invalid command/argument  8110
setstate MAX_04e0e0 2024-11-26 21:11:33 firmware 1.3
setstate MAX_04e0e0 2024-11-26 21:11:33 msgcnt 5
setstate MAX_04e0e0 2024-11-26 21:12:47 onoff 0
setstate MAX_04e0e0 2024-11-26 21:12:47 rferror 1
setstate MAX_04e0e0 2024-11-26 21:12:47 state closed (rf error)
setstate MAX_04e0e0 2024-11-26 21:11:33 testresult 15
setstate MAX_04e0e0 2024-11-26 21:12:47 windowOpen 0


Bei einem Zustandswechsel bekomme ich jetzt meist 3 (manchmal auch 2) Events (ebenso 3x Blinken am Kontakt selbst). Normal sollte ja ein Blinken und ein Event sein. Hier mal daas Log vom

Öffnen

Code Auswählen Erweitern

2024.11.26 21:11:46 4: SIGNALesp32/msg READ: ␂MN;D=0B01063004E0E06543210012F0BB;N=15;r;␃
2024.11.26 21:11:46 4: SIGNALesp32 Parse_MN: Found 2-FSK Protocol id 215 length 28 RSSI = -82 -> MAX
2024.11.26 21:11:46 4: SIGNALesp32 ParseMN: ID=215 dmsg=Z0B01063004E0E06543210012
2024.11.26 21:11:46 4: SIGNALesp32 Dispatch: Z0B01063004E0E06543210012, -82 dB, dispatch
2024.11.26 21:11:46 4: cmax, C: 01, F: 06, T: 30, S: 04E0E0 D: 654321 G: 00 P: 12
2024.11.26 21:11:46 4: cmax, IODev SIGNALesp32, flags 06, msgcnt 01, msgType ShutterContactState, src 04e0e0 ShutterContact, dst 654321 CUL_MAX, group 0, payload 12, rssi -82
2024-11-26 21:11:46 MAX MAX_04e0e0 opened
2024-11-26 21:11:46 MAX MAX_04e0e0 RSSI: -82
2024-11-26 21:11:46 MAX MAX_04e0e0 battery: ok
2024-11-26 21:11:46 MAX MAX_04e0e0 batteryState: ok
2024-11-26 21:11:46 MAX MAX_04e0e0 rferror: 0
2024-11-26 21:11:46 MAX MAX_04e0e0 onoff: 1


2024.11.26 21:11:50 4: SIGNALesp32/msg READ: ␂MN;D=0B01063004E0E06543210012EBBC;N=15;r;␃
2024.11.26 21:11:50 4: SIGNALesp32 Parse_MN: Found 2-FSK Protocol id 215 length 28 RSSI = -84.5 -> MAX
2024.11.26 21:11:50 4: SIGNALesp32 ParseMN: ID=215 dmsg=Z0B01063004E0E06543210012
2024.11.26 21:11:50 4: SIGNALesp32 Dispatch: Z0B01063004E0E06543210012, -84.5 dB, dispatch
2024.11.26 21:11:50 4: cmax, C: 01, F: 06, T: 30, S: 04E0E0 D: 654321 G: 00 P: 12
2024.11.26 21:11:50 4: cmax, IODev SIGNALesp32, flags 06, msgcnt 01, msgType ShutterContactState, src 04e0e0 ShutterContact, dst 654321 CUL_MAX, group 0, payload 12, rssi -84.5
2024-11-26 21:11:50 MAX MAX_04e0e0 opened
2024-11-26 21:11:50 MAX MAX_04e0e0 RSSI: -84.5
2024-11-26 21:11:50 MAX MAX_04e0e0 battery: ok
2024-11-26 21:11:50 MAX MAX_04e0e0 batteryState: ok
2024-11-26 21:11:50 MAX MAX_04e0e0 rferror: 0
2024-11-26 21:11:50 MAX MAX_04e0e0 onoff: 1

Schließen

Code Auswählen Erweitern

2024.11.26 21:11:51 4: SIGNALesp32/msg READ: ␂MN;D=0B02063004E0E06543210010EFB8;N=15;r;␃
2024.11.26 21:11:51 4: SIGNALesp32 Parse_MN: Found 2-FSK Protocol id 215 length 28 RSSI = -82.5 -> MAX
2024.11.26 21:11:51 4: SIGNALesp32 ParseMN: ID=215 dmsg=Z0B02063004E0E06543210010
2024.11.26 21:11:51 4: SIGNALesp32 Dispatch: Z0B02063004E0E06543210010, -82.5 dB, dispatch
2024.11.26 21:11:51 4: cmax, C: 02, F: 06, T: 30, S: 04E0E0 D: 654321 G: 00 P: 10
2024.11.26 21:11:51 4: cmax, IODev SIGNALesp32, flags 06, msgcnt 02, msgType ShutterContactState, src 04e0e0 ShutterContact, dst 654321 CUL_MAX, group 0, payload 10, rssi -82.5
2024-11-26 21:11:51 MAX MAX_04e0e0 closed
2024-11-26 21:11:51 MAX MAX_04e0e0 RSSI: -82.5
2024-11-26 21:11:51 MAX MAX_04e0e0 battery: ok
2024-11-26 21:11:51 MAX MAX_04e0e0 batteryState: ok
2024-11-26 21:11:51 MAX MAX_04e0e0 rferror: 0
2024-11-26 21:11:51 MAX MAX_04e0e0 onoff: 0
2024-11-26 21:11:51 MAX MAX_04e0e0 windowOpen: 0

2024.11.26 21:11:57 4: SIGNALesp32/msg READ: ␂MN;D=0B02063004E0E06543210010F1BA;N=15;r;␃
2024.11.26 21:11:57 4: SIGNALesp32 Parse_MN: Found 2-FSK Protocol id 215 length 28 RSSI = -81.5 -> MAX
2024.11.26 21:11:57 4: SIGNALesp32 ParseMN: ID=215 dmsg=Z0B02063004E0E06543210010
2024.11.26 21:11:57 4: SIGNALesp32 Dispatch: Z0B02063004E0E06543210010, -81.5 dB, dispatch
2024.11.26 21:11:57 4: cmax, C: 02, F: 06, T: 30, S: 04E0E0 D: 654321 G: 00 P: 10
2024.11.26 21:11:57 4: cmax, IODev SIGNALesp32, flags 06, msgcnt 02, msgType ShutterContactState, src 04e0e0 ShutterContact, dst 654321 CUL_MAX, group 0, payload 10, rssi -81.5
2024-11-26 21:11:57 MAX MAX_04e0e0 closed
2024-11-26 21:11:57 MAX MAX_04e0e0 RSSI: -81.5
2024-11-26 21:11:57 MAX MAX_04e0e0 battery: ok
2024-11-26 21:11:57 MAX MAX_04e0e0 batteryState: ok
2024-11-26 21:11:57 MAX MAX_04e0e0 rferror: 0
2024-11-26 21:11:57 MAX MAX_04e0e0 onoff: 0
2024-11-26 21:11:57 MAX MAX_04e0e0 windowOpen: 0

024.11.26 21:12:05 4: SIGNALesp32/msg READ: ␂MN;D=0B02063004E0E06543210010F0B8;N=15;r;␃
2024.11.26 21:12:05 4: SIGNALesp32 Parse_MN: Found 2-FSK Protocol id 215 length 28 RSSI = -82 -> MAX
2024.11.26 21:12:05 4: SIGNALesp32 ParseMN: ID=215 dmsg=Z0B02063004E0E06543210010
2024.11.26 21:12:05 4: SIGNALesp32 Dispatch: Z0B02063004E0E06543210010, -82 dB, dispatch
2024.11.26 21:12:05 4: cmax, C: 02, F: 06, T: 30, S: 04E0E0 D: 654321 G: 00 P: 10
2024.11.26 21:12:05 4: cmax, IODev SIGNALesp32, flags 06, msgcnt 02, msgType ShutterContactState, src 04e0e0 ShutterContact, dst 654321 CUL_MAX, group 0, payload 10, rssi -82
2024-11-26 21:12:05 MAX MAX_04e0e0 closed
2024-11-26 21:12:05 MAX MAX_04e0e0 RSSI: -82
2024-11-26 21:12:05 MAX MAX_04e0e0 battery: ok
2024-11-26 21:12:05 MAX MAX_04e0e0 batteryState: ok
2024-11-26 21:12:05 MAX MAX_04e0e0 rferror: 0
2024-11-26 21:12:05 MAX MAX_04e0e0 onoff: 0
2024-11-26 21:12:05 MAX MAX_04e0e0 windowOpen: 0

Da ich auf die Events ein Notify habe, löst das mehrfach aus. Vorher mit Cube kamen jeweils nur ein Event. Mein Problem ist jetzt nicht das Notify sondern die mehrfachen Meldungen, Die benötigen Energie und die Akkus werden sicher deutlich schneller leergesaugt.

Oft bekomme ich auch einen RF Error bei Schließen:

Code Auswählen Erweitern

2024.11.26 21:32:51 4: SIGNALesp32/msg READ: ␂MN;D=0B08063004E0E06543210050F1B8;N=15;r;␃
2024.11.26 21:32:51 4: SIGNALesp32 Parse_MN: Found 2-FSK Protocol id 215 length 28 RSSI = -81.5 -> MAX
2024.11.26 21:32:51 4: SIGNALesp32 ParseMN: ID=215 dmsg=Z0B08063004E0E06543210050
2024.11.26 21:32:51 4: SIGNALesp32 Dispatch: Z0B08063004E0E06543210050, -81.5 dB, dispatch
2024.11.26 21:32:51 4: cmax, C: 08, F: 06, T: 30, S: 04E0E0 D: 654321 G: 00 P: 50
2024.11.26 21:32:51 4: cmax, IODev SIGNALesp32, flags 06, msgcnt 08, msgType ShutterContactState, src 04e0e0 ShutterContact, dst 654321 CUL_MAX, group 0, payload 50, rssi -81.5
2024-11-26 21:32:51 MAX MAX_04e0e0 closed (rf error)
2024-11-26 21:32:51 MAX MAX_04e0e0 RSSI: -81.5
2024-11-26 21:32:51 MAX MAX_04e0e0 battery: ok
2024-11-26 21:32:51 MAX MAX_04e0e0 batteryState: ok
2024-11-26 21:32:51 MAX MAX_04e0e0 rferror: 1
2024-11-26 21:32:51 MAX MAX_04e0e0 onoff: 0
2024-11-26 21:32:51 MAX MAX_04e0e0 windowOpen: 0


[Ralf9]

Wurde mit dem raw Befehl Za654321 die MaxID auf dem sduino gespeichert?

Abfragen kannst Du es mit "get SIGNALesp32 raw Zg"

[SalvadoreXXL]

Code Auswählen Erweitern

raw: autoAckAddr:000000 fakeWallTAddr:111111


[Ralf9]

Da fehlt noch "set SIGNALesp32 raw Za654321"
danach ergibt get raw Zg
autoAckAddr:654321 fakeWallTAddr:111111

[SalvadoreXXL]

Ist es dabei egal, welches Modul ausgewählt ist? Dann neu pairen?

[Ralf9]

Ja, ist egal welches Modul ausgewählt ist.
Du musst auch nicht neu pairen.

[SalvadoreXXL]

Jetzt scheint es zu funktionieren. Hab das wohl überlesen. Ich beobachte weiter