Zweiter CUL zur Reichweitenerhöhung

[Peer.Gynt]

Nach mehreren Tagen Recherche und finalem Fehlschlag benötige ich nun Hilfe und bedanke mich im Voraus!

Problem: Immer wiederkehrende "missing ack" im Log deuten auf ein Reichweitenproblem hin, da drei Etagen mit einem Anbau versorgt werden müssen.

Lösungsansatz: Ein gebraucht gekaufter busware CUL (V 1.67 CUL868) und der bereits vorhandene busware CUL (V 1.68 CUL868) sollen so platziert werden, dass im EG und im 2.OG gesendet und empfangen werden kann.

Bisher:

• Der neue CUL (Name CUL1) wurde von FHEM erkannt und mittels "set CUL1 rfmode MAX" auf die Max!-Geräte eingeschworen.
• CUL1 kommuniziert auch bereits mit meinem CUL_MAX-Device cm0, ist dort aber natürlich nicht das IODev, das ist weiterhin CUL0

Da die Max!-Geräte ja nicht mit dem CUL selbst sondern dem CUL_MAX-Device kommunizieren, wollte ich ein zweites CUL_MAX-Device anlegen, gemäß https://forum.fhem.de/index.php?msg=870230

Lösung 1 bei großen Gebäuden : mehr als ein cm Device (mit unterschiedlicher ID ) und jedem cm ein eigenes I/O Device (CUL,CUNO) zuordnen.

Leider scheitere ich hier, da mir egal mit welcher willkürlich gewählten ID immer gesagt wird, dass es bereits ein CUL_MAX-Device mit dieser ID gibt.

Code Auswählen Erweitern

define cm1 CUL_MAX 654321: a CUL_MAX device with address 654321 is already defined !
define cm1 CUL_MAX 160465: a CUL_MAX device with address 160465 is already defined !
define cm1 CUL_MAX 180765: a CUL_MAX device with address 180765 is already defined !
define cm1 CUL_MAX 231139: a CUL_MAX device with address 231139 is already defined !
Laut fhem.cfg gibt es aber nur das erste Device mit der ID 123456

Code Auswählen Erweitern

define cm0 CUL_MAX 123456
Am zweiten CUL_MAX-Device cm1 wollte ich dann den zweiten CUL (CUL1) als IODev eintragen und cm1 bei den entsprechende Geräten als IODev eintragen.
Das erschien mir logisch, leider scheitere ich aber eben am Erstellen eines zweiten CUL_MAX-Device.

Hat jemand eine Idee oder kann mir vom Schlauch runterhelfen?


Der Vollständigkeit halber hier die Infos zu CULs und CUL_MAX:

CULO

Code Auswählen Erweitern

define CUL0 CUL /dev/ttyACM0@9600 0000
attr CUL0 rfmode MAX
#   CMDS       ABCeFGhiKkLlMmNRTtUuVWXxYZ
#   CUL0_MSGCNT 70
#   CUL0_TIME  2025-03-04 16:35:17
#   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
#   DEF        /dev/ttyACM0@9600 0000
#   DeviceName /dev/ttyACM0@9600
#   FD         6
#   FHTID      0000
#   FUUID      67a65020-f33f-9d58-d249-4272d768c486096e
#   NAME       CUL0
#   NR         42
#   NR_CMD_LAST_H 6
#   PARTIAL   
#   RAWMSG     Z0E3802021698F9123456000118002206
#   RSSI       -71
#   STATE      Initialized
#   TYPE       CUL
#   VERSION    V 1.68 CUL868
#   devioNoSTATE 1
#   eventCount 29
#   initString X21
#Zr
#Za123456
#Zw111111
#   MatchList:
#     1:CUL_MAX  ^Z........................
#     8:HMS      ^810e04....(1|5|9).a001
#     D:CUL_IR   ^I............
#     H:STACKABLE_CC ^\*
#     M:TSSTACKED ^\*
#     N:STACKABLE ^\*
#   READINGS:
#     2025-03-04 12:34:41   cmds             A B C e F G h i K k L l M m N R T t U u V W X x Y Z
#     2025-03-04 16:35:16   credit10ms      900
#     2025-03-04 16:35:17   state           Initialized
#   XMIT_TIME:
#     1741098917.94856
#     1741099559.06329
#     1741100429.13131
#     1741100435.63964
#     1741101407.60795
#     1741102516.47518
#
setstate CUL0 2025-03-04 12:34:41 cmds  A B C e F G h i K k L l M m N R T t U u V W X x Y Z
setstate CUL0 2025-03-04 16:35:16 credit10ms 900
setstate CUL0 2025-03-04 16:35:17 state Initialized

CUL1

Code Auswählen Erweitern

define CUL1 CUL /dev/ttyACM1@9600 1134
attr CUL1 rfmode MAX
#   CFGFN     
#   CMDS       ABbCeFGhiKkLlMmNRTtUuVWXxYZ
#   CUL1_MSGCNT 121
#   CUL1_TIME  2025-03-04 16:39:03
#   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
#   DEF        /dev/ttyACM1@9600 1134
#   DeviceName /dev/ttyACM1@9600
#   FD         4
#   FHTID      1134
#   FUUID      67c6e551-f33f-9d58-2f68-8497ae696f17ecf2
#   NAME       CUL1
#   NR         89
#   PARTIAL   
#   RAWMSG     Z0F0004601BB7B60000000018032200B31B
#   RSSI       -60.5
#   STATE      Initialized
#   TYPE       CUL
#   VERSION    V 1.67 CUL868
#   devioNoSTATE 1
#   eventCount 3
#   initString X21
#Zr
#   MatchList:
#     1:CUL_MAX  ^Z........................
#     8:HMS      ^810e04....(1|5|9).a001
#     D:CUL_IR   ^I............
#     H:STACKABLE_CC ^\*
#     M:TSSTACKED ^\*
#     N:STACKABLE ^\*
#   READINGS:
#     2025-03-04 12:34:41   cmds             A B b C e F G h i K k L l M m N R T t U u V W X x Y Z
#     2025-03-04 16:39:03   state           Initialized
#
setstate CUL1 2025-03-04 12:34:41 cmds  A B b C e F G h i K k L l M m N R T t U u V W X x Y Z
setstate CUL1 2025-03-04 16:39:03 state Initialized

und CUL_MAX cm0

Code Auswählen Erweitern

define cm0 CUL_MAX 123456
attr cm0 IODev CUL0
attr cm0 fakeSCaddr 222222
attr cm0 fakeWTaddr 111111
#   CUL0_MSGCNT 71
#   CUL0_RAWMSG Z0F0004601BB7B60000000018032200B3
#   CUL0_RSSI  -68
#   CUL0_TIME  2025-03-04 16:39:03
#   CUL1_MSGCNT 122
#   CUL1_RAWMSG Z0F0004601698E500000000180D2200AC
#   CUL1_RSSI  -65.5
#   CUL1_TIME  2025-03-04 16:39:42
#   DEF        123456
#   FUUID      67a65021-f33f-9d58-f423-a5573eaefdbfdf65
#   IODev      CUL0
#   LASTInputDev CUL1
#   MSGCNT     132
#   NAME       cm0
#   NR         43
#   STATE      CUL0:ok
#   SVN        22175
#   TYPE       CUL_MAX
#   addr       123456
#   cnt        0
#   eventCount 159
#   pairmode   0
#   retryCount 0
#   sq         0
#   160465:
#   180765:
#   231139:
#   654321:
#   READINGS:
#     2025-03-04 12:34:46   IODev           CUL0
#     2025-03-04 16:39:42   state           CUL0:ok
#   sendQueue:
#
setstate cm0 CUL0:ok
setstate cm0 2025-03-04 12:34:46 IODev CUL0
setstate cm0 2025-03-04 16:39:42 state CUL0:ok


[Wzut]

nein keine zwei CM Devices anlegen , Beta Module nehmen und dann mit einem CM Device und IO Group arbeiten -> https://forum.fhem.de/index.php?msg=1031078

[Peer.Gynt]

Danke für die rasche Antwort.

Eigentlich dachte ich ja, dass die 2019/2020 genannten Beta-Module bereits NICHT MEHR im Beta-Status sind, da mir

Code Auswählen Erweitern

14_CUL_MAX.pm     22175 2020-06-13 17:32:49Z Wzut
10_MAX.pm         23517 2021-01-13 15:38:49Z Wzutangezeigt werden.

Dann versuche ich mal rauszukriegen, wie ich an die Beta-Module komme... ist vermutlich ganz einfach...

[Peer.Gynt]

BTW: Leider fehlt mir hier oft ein "weil", um ein Verständnis zu entwickeln.

Wenn ich zuerst "mehr als ein cm Device" als Lösung finde, dann aber "keine zwei CM Devices" als Reaktion vom gleichen Autor lese, dann fehlt mir einfach der eigene Lerneffekt...

Das soll keine Kritik sein, da ich als Betreiber von 3 eigenen Foren weiß, dass man bei manchen Fragen "gaaaanz ruuuuhig" bleiben muss. Ich persönlich erkläre dann gerne die Hintergründe...

[Peer.Gynt]

Dann möchte ich das nun mal selbst, da ich es nirgends in für mich verständlicher Form gefunden habe, hier kurz erläutern:

(Zur Info: Windows Nutzer, der Linux-Server zwar nutzt, diese aber meist über Tools wie FileZilla oder PLESK managed und nur zur Not die Linux-Kommandozeile mittels Putty/SSH ansteuert)

Also...

1.) die MAX-Beta-Module finden sich hier im ersten Beitrag -> https://forum.fhem.de/index.php?topic=115018.0
2.) beschrieben werden sie hier -> https://forum.fhem.de/index.php?topic=106258.0

3.) die heruntergeladenen Module 10_MAX.pm und 14_CUL_MAX.pm habe ich per FTP ins Verzeichnis /temp auf den RPi geladen

4.) mittels Putty auf dem RPi eingeloggt und dann mittels

Code Auswählen Erweitern

sudo -su fhem
cd /in die Rolle des fhem-Users geschlüpft, weil sonst die Berechtigungen nicht passen, und ins root gewechselt

5.) mittels

Code Auswählen Erweitern

cp tmp/10_MAX.pm /opt/fhem/FHEM/10_MAX.pm
cp tmp/14_CUL_MAX.pm /opt/fhem/FHEM/14_CUL_MAX.pmdie Dateien kopiert

6) in der FHEM-Kommandozeile "shutdown restart" und mit "version" kontrolliert

Code Auswählen Erweitern

# $Id: 14_CUL_MAX.pm Beta TEST 11.11.24 $
# $Id: 10_MAX.pm BETA TEST $
7) im CUL_MAX-Device cm0 die beiden CULs als IOgrp angegeben

Code Auswählen Erweitern

ATTR cm0 IOgrp CUL0,CUL1
8.) nun tauchen sukzessive CULdev-Attribute bei den Devices auf, die dem jeweiligen CUL zugeordnet werden können. Dabei helfen Einträge im Log, die auf eine bessere Empfangsoption hinweisen

Code Auswählen Erweitern

EG_Wozi, CUL1 has better RSSI values than the current preferred CULdev !
Vielleicht hilft das auch anderen Usern, die wie ich nicht so Linux- und Kommandozeilen-affin sind
Falls ich damit unnötig Dinge erkläre, die sowieso allen klar sind, dann bitte ich um Entschuldigung.


Nachtrag:
- Leider verschwinden bei allen Thermostaten die Wähler für die Wunschtemperatur und müssen mittels "attr DEVICE webCmd desiredTemperature" wieder sichtbar gemacht werden
- Einige Minuten stockte die Erstellung von SVG-Plots, wenn mehrere auf einer Seite erscheinen. Geht nun wieder...

[Wzut]

Wenn ich zuerst "mehr als ein cm Device" als Lösung finde, dann aber "keine zwei CM Devices" als Reaktion vom gleichen Autor lese, dann fehlt mir einfach der eigene Lerneffekt...

manchmal entwickelt sich halt etwas weiter und dann gilt auch für mich der alte Spruch :

Was interessiert mich mein Geschwätz von gestern

BTW : zwei CULS vua USB ? Wie bekommst du da den einen näher an die MAX Geräte ?
Bei mir werkelt 1 x USB und 2 x LAN im Haus

[Peer.Gynt]

BTW : zwei CULS vua USB ? Wie bekommst du da den einen näher an die MAX Geräte ?
Bei mir werkelt 1 x USB und 2 x LAN im Haus

Die zwei CULs sind jeweils mit einem 1,50m/1,80m Kabel angeschlossen, damit reicht diese Spanne im Treppenhaus von Oberkante EG bis Unterkante 2. OG.
Witzigerweise - da wohl automatisiert das stärkere Signal als CUL genutzt wird - nutzen Geräte aus dem EG das CUL im 2. OG...

Da ich noch 3 Cubes mit Amnesie rumfliegen habe, muss ich mir dafür mal Gedanken übers umflashen machen, denn LAN-Kabel liegen überall...

manchmal entwickelt sich halt etwas weiter

dennoch hätte mich interessiert, warum das Erstellen eines zweiten CM-Device so gar nicht funktioniert, wenn es doch früher mal eine Lösung war... 

[Wzut]

a.) wer der "beste" CUL für das jeweilige Gerät ist entscheidest du. Die Readings CUL1st & CUL2nd geben dir mit ihren RSSI Werten eine Hilfestellung bzw. auch die Log Meldung die du ja endeckt hast. Der Cuve ist ein gutes LAN IO Device. Seit neustem geht ja auch SIGNALduino via WLAN.

b.) der von die verlinkte Post stammt aus dem Jahre 2018 !! Damals war ich weder hier Moderator noch hatte ich etwas mit den MAX Modulen als Entwikler zu tun (das war da noch M.Gehre)
D.h. 2018 konnte man wohl noch zwei CMs definieren, was aber später von M.G. dann verhindert wurde. Ich habe das bei der Übernahme nicht in Frage gestellt, da mir durch meine Homatic Erfahrung  ich die heutige Lösung mit der IOgrp schon im Hinterkopf hatte.

[Peer.Gynt]

a.) wer der "beste" CUL für das jeweilige Gerät ist entscheidest du. Die Readings CUL1st & CUL2nd geben dir mit ihren RSSI Werten eine Hilfestellung bzw. auch die Log Meldung die du ja endeckt hast. Der Cuve ist ein gutes LAN IO Device. Seit neustem geht ja auch SIGNALduino via WLAN.

b.) der von die verlinkte Post stammt aus dem Jahre 2018 !! Damals war ich weder hier Moderator noch hatte ich etwas mit den MAX Modulen als Entwikler zu tun (das war da noch M.Gehre)
D.h. 2018 konnte man wohl noch zwei CMs definieren, was aber später von M.G. dann verhindert wurde. Ich habe das bei der Übernahme nicht in Frage gestellt, da mir durch meine Homatic Erfahrung  ich die heutige Lösung mit der IOgrp schon im Hinterkopf hatte.

zu a.) ja, weiteres Stöbern hat das Attribut autoselectCUL als Gegenwehr gegen die automatische Auswahl ausfindig gemacht. Und das Attribut IODev im CUL_MAX-Device musste ich auch noch manuell löschen.
Bisher gehe ich davon aus, dass ich den/die Cube/s umflashen muss, oder kann man die auch einfach so einsetzen, da sie sämtliche Pairungs und Einstellungen ja sowieso vergessen haben?

zu b.) ja, sorry, wenn ich so altes Zeug ausgrabe, aber es klang halt nach der gesuchten Lösung.
Die Fehlermeldung

Code Auswählen Erweitern

define cm1 CUL_MAX 654321: a CUL_MAX device with address 654321 is already defined !lässt ja auch vermuten, dass das Problem tatsächlich die ID ist und nicht dass es nur ein CUL_MAX-Device geben kann. Besser wäre da

Code Auswählen Erweitern

define cm1 CUL_MAX 654321: a CUL_MAX device is already defined !
Auf jeden Fall Danke für Deine Hilfestellungen und die Modulentwicklung!

[Wzut]

Bisher gehe ich davon aus, dass ich den/die Cube/s umflashen muss

ja, damit er zum CUNO wird. Telekatz hat da richtig Arbeit reingesteckt -> http://forum.fhem.de/index.php/topic,38404.0.html

[Peer.Gynt]

Super, danke! Dann werde ich das mal angehen...


Übrigens: Nachdem die Beta-Module 12 Stunden ohne Probleme liefen, verweigerten plötzlich sämtliche Thermostate das ACK, egal ob durch MaxScanner oder manuell eine Änderung angefordert wurde, und somit waren die beiden CULs natürlich permanent ohne Credits.

Durch einige Forenbeiträge deutete alles auf eine fehlendes Pairing hin, aber das war nun nicht der Fall und ein testweises Re-Pairing meckerte über eine falsche MaxID.
Ursache war wohl meine Reaktion auf die Meldung "cm, please set attribute maxid on CUL0 !" die mir im Log mehrfach nach dem Installieren der Beta-Module begegnete. Also habe ich für beide CULs eine willkürliche MaxID per Attribut vergeben, ca. 8 Stunden bevor die Geräte plötzlich nichts mehr vom CUL_MAX hören wollten.
Ich habe nun bei beiden CULs die MaxID des CUL_MAX eingetragen und sofort hören wieder alle Geräte auf die CULs.
Ich dachte, die IDs sollten eindeutig sein, aber entweder sollte die ID des CUL_MAX eingetragen werden oder man sollte die Meldung ignorieren.
Leider habe ich erst beim Schreiben dieses Posts einen entsprechenden Forumseintrag gefunden -> https://forum.fhem.de/index.php?topic=107424.0
Also: bei allen CULs die addr/DEF vom CUL_MAX als MaxID eintragen.

(Vielleicht sucht ja noch jemand nach einer Erklärung...)

[Wzut]

egal ob durch MaxScanner

Ich würde mir gut überlegen ob es sich sich wirklich lohnt diesen Creditsfresser einzusetzen, zumal dir als Nutzer der Beta Module ein eleganterer Weg offensteht um das jerweilige HT direkt zu fragen ohne ständig die Soll Temp hoch und runter zu schrauben -> https://forum.fhem.de/index.php?msg=1297107

[Peer.Gynt]

Ich würde mir gut überlegen ob es sich sich wirklich lohnt diesen Creditsfresser einzusetzen, zumal dir als Nutzer der Beta Module ein eleganterer Weg offensteht um das jerweilige HT direkt zu fragen ohne ständig die Soll Temp hoch und runter zu schrauben -> https://forum.fhem.de/index.php?msg=1297107

Da hast Du natürlich völlig recht, bisher war es aber für mich die einzige Möglichkeit stundenlange Lücken in den Plots zu vermeiden.

Jetzt muss ich nur

In der IstUndBleibtEwigBetaVersion (läuft prächtig! Danke an @Wzut) von Wzut gibt es ein "Set" namens "getStatus", welche die aktuell gemessene Temperatur liefert.
Ich frage periodisch alle Thermostate damit ab und habe damit keine verbogenen Grafiken!

für mich übersetzen, um rauszukriegen, wie ich ein "frage periodisch alle Thermostate ab" umsetze. Da war der MaxScanner ganz praktisch, da man nur das Intervall definieren musste und los. Aber ich suche mal in der commandref...

[Wzut]

ich suche mal in der commandref...

at ist da dein Freund , mit + und * zb alle 30 Minuten  ->

Code Auswählen Erweitern

define at_HT_Bad at +*00:30:00 set HT_Bad getStatus
1. Man kann so nun X ats anlegen für X HT
2. Man kann Komma getrennt mehr als ein FHEM auf einmal ansprechen -> set HT_Bad,HT_Kind,HT_Kueche getStatus
ist IMHO aber suboptimal, da alles fast zur gleichen Zeit raus geht und sich ggf. die Antworten überschneiden.
3. Beste Varianten :
 a.)  eine LightScene definieren, da alle gewünschten HTs reinpacken und mit dem Attribut async_delay eine Wartezeit zwischen jede Abfrage setzen.
 b.) eine beliebige Wartezeit kann man mit sleep auch im at realisieren dazu muss man allerdings im Ausführungsteil in den Perl Mode wechseln , zb :

Code Auswählen Erweitern

define at_alle_HTs at +*00:30:00  { fhem('set HT_Kueche getStatus'); sleep(10); fhem('set HT_Bad getStatus'); sleep(10); fhem('set HT_Flur getStatus');}
 

[rudolfkoenig]

define at_alle_HTs at +*00:30:00  { fhem('set HT_Kueche getStatus'); sleep(10); fhem('set HT_Bad getStatus'); sleep(10); fhem('set HT_Flur getStatus');}

Bitte so nicht einsetzen, da die perl sleep Funktion FHEM blockiert.
Besser den FHEM-internen sleep Befehl verwenden, das blockiert nicht.

Code Auswählen Erweitern

define at_alle_HTs at +*00:30:00 set HT_Kueche getStatus';; sleep 10;; set HT_Bad getStatus';; sleep 10;; set HT_Flur getStatus

Etwas Off-Topic: { fhem("set A");; fhem("sleep 10");; fhem("set B") } ist _KEINE_ Alternative, da wird set B direkt nach set A ausgefuehrt.

Weiterhin: beim Modifizieren des Befehls auf der FHEMWEB Detailseite reicht ein ; weil FHEMWEB das stillschweigend durch ;; ersetzt.
Wenn man den Befehl in der FHEMWEB Uebersicht oder in fhem.cfg direkt pflegt, dann muss man selbst fuer ;; sorgen.