Probleme mit mehreren CUNX / CUBe und MAX

Begonnen von zweiundzwanzig, 01 März 2016, 18:28:22

Vorheriges Thema - Nächstes Thema

zweiundzwanzig

Hallo,
ich habe das gefühl, dass sich meine CUNX / CUBe gegenseitig stören. Könnt ihr euch das bitte mal ansehen?

Ich habe folgendes Setup:
attr global userattr Vorheizzeit cmdIcon devStateIcon devStateStyle icon sortby webCmd widgetOverride
attr global autoload_undefined_devices 1
attr global backup_before_update 1
attr global logfile ./log/fhem-%Y-%m.log
attr global modpath .
attr global sendStatistics onUpdate
attr global statefile ./log/fhem.save
attr global updateInBackground 1
attr global verbose 3

# Fake FileLog entry, to access the fhem log from FHEMWEB
define Logfile FileLog ./log/fhem-%Y-%m.log fakelog
attr Logfile room logs

define autocreate autocreate
attr autocreate disable 0
attr autocreate filelog ./log/%NAME-%Y.log
attr autocreate weblink 1

define eventTypes eventTypes ./log/eventTypes.txt

define CUNX_1 CUL 192.168.100.203:2323 0000
attr CUNX_1 rfmode MAX
attr CUNX_1 sendpool CUNX_1,CUNX_2,CUBe
define CULMAX_1 CUL_MAX 123456
attr CULMAX_1 IODev CUNX_1

define CUNX_2 CUL 192.168.100.202:2323 0000
attr CUNX_2 rfmode MAX
attr CUNX_2 sendpool CUNX_1,CUNX_2,CUBe
define CULMAX_2 CUL_MAX 123457
attr CULMAX_2 IODev CUNX_2

define CUBe CUL 192.168.100.204:2323 0000
attr CUBe rfmode MAX
attr CUBe sendpool CUNX_1,CUNX_2,CUBe
define CULMAX_3 CUL_MAX 012345
attr CULMAX_3 IODev CUBe



CUNX_1 und CUNX_2 liegen räumlich weit auseinander, haben aber zueinander noch etwa RSSI -98. Der CUBe liegt zwischen den beiden.

Wenn ich ein Gerät mit CUNX_1 oder CUNX_2 paire klappt das, bis auf die ab und zu vorkommenden missing ACK ganz normal.
Wenn ich versuche mit dem CUBe ein neues Gerät zu pairen geht das in dem setup nicht. Ich empfange aber von dem Gerät Daten.
Wenn ich dann CUNX_1 und CUNX_2 abschalte (z.B. auf einem anderes rfmode schalte) kann ich CUBe mit dem Gerät verwenden.

Hat jemand eine Idee woran das liegen kann? Ich verzweifle langsam.
2x MAX CuBe mit a-culf im Moritzbetrieb
1x MAX CuBe mit a-culf im Homematicbetrieb
60x MAX Heizkörperthermostat plus | 2x HM Schaltaktoren | 1x MAX Wandthermostat
1x FHEM Ubuntu Server auf VMWare
24 Räume, die durch ical Kalender geheizt werden

zweiundzwanzig

Das ganze ist auch noch an folgende Frage gekoppelt:

Ich habe verschiedene rf addresses für die CULMAX genutzt. Theoretisch könnten die ja auch alle die gleiche rf adress haben, wenn ich steuern kann, welcher CUNX/CUBe für das Senden zuständig sein soll. Wäre das eigentlich möglich? Mehrere CULMAX mit der gleichen Adresse, die jeweils auf einen speziellen CUNX / CUBe zeigen?
2x MAX CuBe mit a-culf im Moritzbetrieb
1x MAX CuBe mit a-culf im Homematicbetrieb
60x MAX Heizkörperthermostat plus | 2x HM Schaltaktoren | 1x MAX Wandthermostat
1x FHEM Ubuntu Server auf VMWare
24 Räume, die durch ical Kalender geheizt werden

zweiundzwanzig

#2
Jetzt wird es noch wirrer.
Einfache Befehle wie "set MAX_Thermostatplus desiredTemperature 14" funktionieren.
Befhele wie "set MAX_Thermostatplus weekProfile Tue 13,0:05,14,22:15,14,23:55,13" nicht. Der macht ein "2016.03.01 21:49:06 2 : CUL_MAX_SendQueueHandler: Missing ack from 0f840f for 193800100123450f840f00053401390b391f3400452045204520"
Aber nur wenn die anderen beiden CUNX an sind. Sonst geht das.

Ich habe noch dashier in meiner fhem.cfg. Damit autocreate nicht immer wieder Wandthermostate anlegen will für die anderen CUNX/CUBe .Ist das richtig?

define MAX_123456 MAX WallMountedThermostat 123456
attr MAX_123456 ignore 1

define MAX_123457 MAX WallMountedThermostat 123457
attr MAX_123457 ignore 1

define MAX_012345 MAX WallMountedThermostat 012345
attr MAX_012345 ignore 1
2x MAX CuBe mit a-culf im Moritzbetrieb
1x MAX CuBe mit a-culf im Homematicbetrieb
60x MAX Heizkörperthermostat plus | 2x HM Schaltaktoren | 1x MAX Wandthermostat
1x FHEM Ubuntu Server auf VMWare
24 Räume, die durch ical Kalender geheizt werden

zweiundzwanzig

Ich habe jetzt mal folgendes probiert:
Ich habe das ioDev bei meinem Thermostat auf CULMAX_1 geändert.

--> Jetzt konnte ich auf das Wochenprogramm ändern.

Dann habe ich dem CULMAX_3 die gleiche rf adresse gegeben, die der CUNX_1 hat. (012345)
Ich habe das ioDev dann wieder zurück auf CULMAX_3 geändert.

--> jetzt konnte ich das Wochenprogramm nicht mehr ändern.

Eigentlich müsste es doch jetzt gehen. Es sei denn in meinem CUBe ist ein Softwarefehler in der Firmware. Ich nutze eine selbstcompilierte (credit10ms hochgesetzt) a-culfw.
2x MAX CuBe mit a-culf im Moritzbetrieb
1x MAX CuBe mit a-culf im Homematicbetrieb
60x MAX Heizkörperthermostat plus | 2x HM Schaltaktoren | 1x MAX Wandthermostat
1x FHEM Ubuntu Server auf VMWare
24 Räume, die durch ical Kalender geheizt werden

Wzut

echt sportlich dein Ansatz mit drei CULs ..... Ich hatte vor Monaten lediglich zwei am Start ( USB+Net) und bin auch über diverse Probleme gestolpert. Habe dann für die Heizperiode mich entschieden ersteinmal nur beim USB CUL zu bleiben und in ein paar Wochen wenn die wärmeren Tage kommen das Thema nochmal von Anfang an aufzurollen.
IMHO liegt das Grundproblem der fhem MAX Module darin das der Autor ein solches komplexes System bei der Entwicklung niemals auf dem Radar hatte. (bis vor ein paar Wochen konnte u.a. ja auch nur ein CULMAX Dev definiert werden)
Meine ToDo Liste sieht z.Z folgend aus :
a. verstehen was beim CUL Modul mit dem Attribut sendpool genau intern abläuft und feststellen ob das in Verbindung mit CULMAX überhaupt sinnvoll ist.
b. CULMAX/MAX mittels zusätzlichen Attributen fest an ein bestimmtes IoDev zu binden (damit sollten dann solche Kunstgriffe wie du es z.Z. mit den ignore 1 machst überflüssig sein)
   
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

zweiundzwanzig

Na, das lässt ja hoffen. Ich habe nämlich noch einen Stapel MAX Thermostate hier liegen und will eigentlich noch 2-3 weiter MAX in einem Gebäudekomplex einbauen :-(
2x MAX CuBe mit a-culf im Moritzbetrieb
1x MAX CuBe mit a-culf im Homematicbetrieb
60x MAX Heizkörperthermostat plus | 2x HM Schaltaktoren | 1x MAX Wandthermostat
1x FHEM Ubuntu Server auf VMWare
24 Räume, die durch ical Kalender geheizt werden

zweiundzwanzig

Gerade ist mir noch folgendes aufgefallen:
Wenn ich erst HTplus desiredTemperature 15 mache scheint das zu funktionieren.
Wenn ich dann das Weekprofile ändern will gibt es ACK Probleme und es stellt auch die desiredTemperature auf 14 zurück.

2016-03-02 17:39:56 MAX HTplus mode: auto
2016-03-02 17:39:56 MAX HTplus battery: ok
2016-03-02 17:39:56 MAX HTplus desiredTemperature: 15.5
2016-03-02 17:39:56 MAX HTplus valveposition: 0
2016-03-02 17:39:56 MAX HTplus 15.5 °C
2016-03-02 17:39:56 MAX HTplus RSSI: -84
2016-03-02 17:40:03 MAX HTplus mode: auto
2016-03-02 17:40:03 MAX HTplus battery: ok
2016-03-02 17:40:03 MAX HTplus desiredTemperature: 15.5
2016-03-02 17:40:03 MAX HTplus valveposition: 0
2016-03-02 17:40:03 MAX HTplus 15.5 °C
2016-03-02 17:40:03 MAX HTplus RSSI: -84
2016.03.02 17:40:05 2 : CUL_MAX_SendQueueHandler: Missing ack from 0f840f for 0b4900400123450f840f001f
2016-03-02 17:40:05 CUL_MAX CULMAX_3 packetsLost: 55
2016-03-02 17:40:12 MAX HTplus weekProfile Sun 13,0:05,14,22:15,14,23:55,13
2016-03-02 17:40:13 MAX HTplus mode: auto
2016-03-02 17:40:13 MAX HTplus battery: ok
2016-03-02 17:40:13 MAX HTplus desiredTemperature: 15.5
2016-03-02 17:40:13 MAX HTplus valveposition: 0
2016-03-02 17:40:13 MAX HTplus 15.5 °C
2016-03-02 17:40:13 MAX HTplus RSSI: -85
2016-03-02 17:40:20 MAX HTplus mode: auto
2016-03-02 17:40:20 MAX HTplus battery: ok
2016-03-02 17:40:20 MAX HTplus desiredTemperature: 14.0
2016-03-02 17:40:20 MAX HTplus valveposition: 0
2016-03-02 17:40:20 MAX HTplus 14.0 °C
2016-03-02 17:40:20 MAX HTplus RSSI: -59.5
2016-03-02 17:40:27 MAX HTplus mode: auto
2016-03-02 17:40:27 MAX HTplus battery: ok
2016-03-02 17:40:27 MAX HTplus desiredTemperature: 14.0
2016-03-02 17:40:27 MAX HTplus valveposition: 0
2016-03-02 17:40:27 MAX HTplus 14.0 °C
2016-03-02 17:40:27 MAX HTplus RSSI: -59.5
2016-03-02 17:40:33 MAX HTplus mode: auto
2016-03-02 17:40:33 MAX HTplus battery: ok
2016-03-02 17:40:33 MAX HTplus desiredTemperature: 14.0
2016-03-02 17:40:33 MAX HTplus valveposition: 0
2016-03-02 17:40:33 MAX HTplus 14.0 °C
2016-03-02 17:40:33 MAX HTplus RSSI: -59.5

2x MAX CuBe mit a-culf im Moritzbetrieb
1x MAX CuBe mit a-culf im Homematicbetrieb
60x MAX Heizkörperthermostat plus | 2x HM Schaltaktoren | 1x MAX Wandthermostat
1x FHEM Ubuntu Server auf VMWare
24 Räume, die durch ical Kalender geheizt werden

zweiundzwanzig

#7
Wenn es bei der Weiterentwicklung des Moduls hilfreich sein kann würde ich ja gerne hier alles posten, was mir auffällt.
Es könnte doch sein, dass das Signal, das der CUBe an das HT+ sended durch irgendetwas, was die CUNX darauf antworten gestört wird oder? Also eine Art Überlagerung, die vor allem bei langen Befehlen eine Rolle spielen.
Wie könnte man so etwas feststellen? Gibt es die Möglichkeit raw zu protokollieren was die CUNX/CUBe sendet und empfängt?
2x MAX CuBe mit a-culf im Moritzbetrieb
1x MAX CuBe mit a-culf im Homematicbetrieb
60x MAX Heizkörperthermostat plus | 2x HM Schaltaktoren | 1x MAX Wandthermostat
1x FHEM Ubuntu Server auf VMWare
24 Räume, die durch ical Kalender geheizt werden

Christian Uhlmann

Hallo zusammen,

ich hätte auch großes interesse hier eine Lösung zu erhalten, mit der ich die Reichweite meiner Installation erhöhen kann.

Mir persönlich würde am ehesten soetwas wie bei Homematic die VCCU (http://www.fhemwiki.de/wiki/Virtueller_Controller_VCCU) weiterhelfen.
Dies ist glaube ich ein guter Ansatz um mehrere IODev's zu nutzen.

Wenn ich beim testen helfen kann gerne.


Grüße

Christian
Host: Debian Buster als VM / XCP-NG
Gateways: DuoFern Stick, CUL433 Revolt, CUL MAX, HMLan, HM-USB 2, LaCrosseGateway
Devices: 12x Rademacher Rollos, 6x TX 29 DT-HT, 10x HM-CC-RT-DN, 14x MAX Fensterkontakte, Diverse HM Aktoren für Licht, Klingel, Gong, Eingangstür, ESPEasy, Sonoff mit Tasmota

Christian Uhlmann

Hallo zusamnmen,

hat sich hier mal etwas getan, hat jemand weitere Erkentnisse?


LG Christian
Host: Debian Buster als VM / XCP-NG
Gateways: DuoFern Stick, CUL433 Revolt, CUL MAX, HMLan, HM-USB 2, LaCrosseGateway
Devices: 12x Rademacher Rollos, 6x TX 29 DT-HT, 10x HM-CC-RT-DN, 14x MAX Fensterkontakte, Diverse HM Aktoren für Licht, Klingel, Gong, Eingangstür, ESPEasy, Sonoff mit Tasmota

Sheridan

Hallo zusammen,

ich habe mir das inzwischen nochmals angeschaut: Es gibt zwei Probleme:

1.) 10_MAX.pm setzt IODev immer auf das letzte Device, über das eine Antwort reinkam. Dadurch wird das nächste Kommando auch über dieses Device versandt. Beispiel: Ich habe in einem Bereich einen Cube und im anderen Bereich einen CUL. Der CUL ist immer schneller. Wenn er also das Paket des Cube-Bereichs doch mal noch empfängt, wird er als IODev eingetragen und fortan werden die Kommandos für dieses MAX Device immer per CUL versendet. Dann kommt es natürlich oft vor, dass die Pakete, die über den CUL rausgehen, im Cube-Bereich nicht mehr ankommen.

Hierfür gibt es zwei Lösungen:
a.) (ungetestet): Den beiden MAX Instanzen unterschiedliche Codenummern geben (define max1 MAX 123456; define max2 MAX 654321) und die Geräte explizit an der jeweiligen MAX Instanz anlernen. Während des Anlernens darf aber nur ein Empfänger aktiv sein wegen dem zweiten Problem (s.u.). Da ich bereits sehr viele Geräte angelernt hatte, wollte ich mir das nicht geben.
b.) Änderung in 10_MAX.pm:


  if($isToMe) {
    $shash->{IODev} = $hash;
    $shash->{backend} = $hash->{NAME}; #for user information
  }


in


  if($isToMe) {
    if(AttrVal($hash->{NAME},"IODev","") eq "") {
      $shash->{IODev} = $hash;
      $shash->{backend} = $hash->{NAME}; #for user information
    }
  }


Damit wird das IODev nicht mehr umgesetzt, wenn per Attribut ein festes IODev zugewiesen ist. Man muss dann den MAX-Geräten einmal jeweils das gewünschte IODev per Attribut zuweisen.

2.) FHEM ignoriert doppelte Meldungen (eigentlich generell eine gute Sache!). Dieses Problem ist schlimmer: Die Ack-Meldungen der Geräte, mit der Kommandos von FHEM bestätigt werden, werden ebenfalls falsch zugewiesen. Beispiel: der MAX am Cube sendet ein Kommando. Das Device bekommt es und antwortet. Der CUL kann es, obwohl eigentlich nicht zuständig, auch noch hören und ist schneller. Da der MAX am CUL aber kein Kommando weggesendet hat, wird das Ack ignoriert. Der Cube empfängt das Ack etwas später und es wird verworfen, weil es eine doppelte Meldung ist (anstelle, dass es vom MAX am Cube erfolgreich bearbeitet wird und damit das gesendete Kommando als erfolgreich abgeschlossen wird). Damit sendet das MAX am Cube das Kommando immer wieder (bis die Retries alle sind).

Hier wäre vermutlich die richtige Lösung, Ack-Meldungen, die nicht für einen selbst sind, weiterzugeben oder deren Duplikate zu ignorieren. Da kenne ich mich aber zu wenig aus, um das ändern zu können.

Abhilfe schafft natürlich auch, die Duplikat-Detektion in FHEM zu deaktivieren. Das geht leider nur Global und nicht für einzelne Devices. Ich habe bei mir den dupTimeout auf 0.05 s gestellt (attribut von global). Dadurch werden die Pakete von CUL/Cube nicht mehr als Duplikate wahrgenommen, da sie in der Regel > 0.1s hintereinander eintreffen. Mit zwei CULs wäre das aber sicher anders, da kommen sie ja fast zeitgleich.

Vielleicht gibt es ja jemanden, der eine Idee hat, wie man das besser lösen kann?

Viele Grüße,
John
FHEM auf RasPi 4 mit CUL (MAX), CUL (IT), JeeLink (LaCrosse), JeeLink (EC3000), DuoFern, Razberry (ZWave) sowie Fritz!Box, Enigma2, Squeezebox, Google Assistant (inkl. Nest Hub 2)
FHEM auf RasPi 3 mit CUL (MAX), TUL (KNX), CUBe (MAX), EnOceanPi (EnOcean)

Christian Uhlmann

Hallo John,

Danke für deine Änderung. Bin. Bisher nicht dazu gekommen das zu testen, werde es aber mal einbauen (Variante b)
Allerdings wird das mit dem Ack wohl  schon ein Problem werden. Hast du da noch eine andere Lösung für?

Grüße Christian

P.S.: schade eigentlich das hier das max System nicht wie Homematic mit einer vccu ähnlichem Konstrukt daher kommt [emoji30]
Host: Debian Buster als VM / XCP-NG
Gateways: DuoFern Stick, CUL433 Revolt, CUL MAX, HMLan, HM-USB 2, LaCrosseGateway
Devices: 12x Rademacher Rollos, 6x TX 29 DT-HT, 10x HM-CC-RT-DN, 14x MAX Fensterkontakte, Diverse HM Aktoren für Licht, Klingel, Gong, Eingangstür, ESPEasy, Sonoff mit Tasmota

zweiundzwanzig

Ah, das ist ja spannend. Ich setze jetzt erstmal den Timeout runter, so wie du das gemacht hast. Ich habe schon jedem CUBE auch ein eigenes CULMAX zugewiesen weil ich dachte, dass man das so machen muss!
2x MAX CuBe mit a-culf im Moritzbetrieb
1x MAX CuBe mit a-culf im Homematicbetrieb
60x MAX Heizkörperthermostat plus | 2x HM Schaltaktoren | 1x MAX Wandthermostat
1x FHEM Ubuntu Server auf VMWare
24 Räume, die durch ical Kalender geheizt werden