MAX und SIGNALduino?

[Wzut]

#    2024-11-26 21:12:47  state          closed (rf error)
3x Blinken am Kontakt selbst

3 mal Blinken = keine Antwort von der Zentrale und damit auch rf error im state

[SalvadoreXXL]

3 mal Blinken = keine Antwort von der Zentrale und damit auch rf error im state

Das war mir schon klar    Allerdings eben nicht immer. Mit set SIGNALesp32 raw Za654321 wurde das gefixt. Habe den Threat hier dazu nochmals abgesucht und nichts dazu gefunden.

[Wzut]

Hättest du meine letzte Beta Version benutzt wäre das Problem nicht aufgetaucht.

[Ralf9]

In der Anlage ist eine neue Beta Version vom CUL_MAX Modul. Beschreibung dazu folgt heute Abend.
Ich habe für den sduino das credit10ms ergänzt. Es gibt jetzt im CUL_MAX Modul ein Reading "IOname_credit10ms" das mit einem InternalTimer alle 10 Sekunden um 10 erhöht wird.

[Ralf9]

Die aktuelle Version vom 00_SIGNALduinoAdv.pm Modul ist nun im github
https://forum.fhem.de/index.php?topic=111653.msg1058900#msg1058900

Hier ist für den ESP32 sduino die Beschreibung und V4.2.3 Firmware
https://forum.fhem.de/index.php?topic=83273.msg755123#msg755123
https://forum.fhem.de/index.php?topic=83273.msg1324774#msg1324774

Bei dem CUL_MAX Modul vom vorherigen Beitrag habe ich u.a. folgendes ergänzt und angepasst:
- Beim sduino wird die maxid für das AutoAck im EEPROM gespeichtert.
  Sie muss deshalb nur einmal am Anfang mit dem raw Befehl Za zum sduino übertragen werden. Mit Zg kann die maxid (autoAckAddr) abgefragt werden.
  z.B. "get sduino raw Za654321"
- Die fakeWallTAddr ist beim sduino fest auf 111111

- Es können als IODev auch mehrere sduinos verwendet werden.
- Bei der updateConfig Routine wird zuerst überprüft ob alle IODev initialisiert sind und eine Version haben, sonst wird die Routine um 20 Sek verzögert.
- Die updateConfig Routine kann auch über get aufgerufen werden.
- Die credits10ms sind beim sduino im CUL_MAX als reading gespeichert (IOname_credit10ms) und werden mit einem InternalTimer alle 10 Sekunden um 10 erhöht.
- Beim Fensterkontakt funktioniert das asso/deasso auch beim Batterie raus (warten) und wieder einlegen.
- Beim pairen wird beim pairPong zum Max Device jetzt das fast send (Zf...) verwendet.

- wenn nur ein IODev (cul/sduino) verwendet wird, muss nur im CUL_MAX das attr IODev angelegt werden, das attr maxid im IODev ist nicht mehr notwendig.
- bei mehreren IODev müssen diese im CUL_MAX im attr IOgrp eingetragen werden. Das attr IODev darf nicht definiert sein.
  Bei den Max Devices müssen im Attr CULdev das IODev eingetragen werden.
  Das attr maxid bei den IODev muss nur angelegt werden, wenn es verschiedene maxid gibt.
  Bei verschiedenen maxid muss bei den Max Device das attr autoselectCUL auf 0 gesetzt werden.

Beim 10_MAX.pm Modul ist mir folgendes aufgefallen:
wenn ich beim WT mit +- die Temperatur ändere, steht im log

Code Auswählen Erweitern

3: MAX_Parse, message for undefined device 654321 and failed to guess devicetype from msg SetTemperature - ignoring !CUL_MAX hat bei mir die DEF 654321
Da wäre eine Abfrage auch nach CUL_MAX sinnvoll, und dann eine log Ausgabe mit verbose 5
z.B.
5: MAX_Parse, message for CUL_MAX device 654321 - ignoring

[Wzut]

wenn ich beim WT mit +- die Temperatur ändere, steht im log

wie machst du das ? Ich würde das gern mal nachstellen.
Ziel ist ja offenbar dein FHEM (65421) und msgtype SetTemperature, d.h. das WT will seiner Zentrale lediglich eine geänderte Soll Temp mitteilen. 

[Ralf9]

Ja, wenn ich mit +- die Solltemperatur ändere, wird diese zur Zentrale gesendet

Code Auswählen Erweitern

4: sduino Dispatch: Z0B26054001CE986543210069, -54 dB, dispatch
4: MAX_654321, C: 26, F: 05, T: 40, S: 01CE98 D: 654321 G: 00 P: 69
4: MAX_654321, IODev sduino, flags 05, msgcnt 26, msgType SetTemperature, src 01ce98 WallMountedThermostat, dst 654321 CUL_MAX, group 0, payload 69, rssi -54