CCU-Jack und MQTT

[gunterc]

OK. Die Sache scheint klar zu sein. @Mathias: Dein Tipp war richtig.

In der /etc/mosquitto/mosquitto.conf muss ein Eintrag wie "remote_clientid Irgendwas" stehen. (natürlich ohne " " ).

Mit "Irgendwas" will ich sagen, dass es wohl egal ist, was da steht. Es ist egal, darf allerdings, wie von Dir vermutet, keinen '.' enthalten. Also "Irgend.Was" geht nicht. Dummerweise ist ein Punkt aber das Default in dieser Client ID, wenn man nicht explizit eine solche setzt.

Ich verstehe das jetzt so:
Der MQTT-Broker, der als Bridge dient, ist aus Sicht eines anderen Brokers (z.B. CCU-Jack) ein Client. Die Bridge schickt dem anderen Broker ihren Namen, damit der Broker die Bridge ansprechen kann. So eine Art CallBack -Funktionalität.
Ich vermute, dass das verwendet wird, wenn in einem System mehrere Bridges wären.

Was ich etwas perfide finde ist das Folgende:
Wenn die remote_clientid falsch ist, also vom CCU-Jack nicht verstanden wird, dann ist das schade, aber nachvollziehbar.
Wenn ich die remote_clientid ändere, sodass sie verstanden wird, funktioniert das System. Das ist gut und nachvollziehbar.
Wenn ich die remote_clientid nun aber wieder auf falsch zurückändere, funktioniert das System immer noch. Das mag man gut finden, ist für mich aber nicht nachvollziehbar.
Hierbei ist es egal, wie ich den Bridge-Broker starte. Auch ein Neustart ändert nichts. In allen Fällen wird die mosquitto.conf aber verwendet, wie der log-Datei zu entnehmen ist.
CCU-Jack ist hier außen vor. Wenn ich die Bridge neu installiere, tritt das Fehlverhalten wieder auf, bis einmal eine funktionierende ID verwendet wird.

Ich habe das deshalb so ausführlich erwähnt, weil das bei Testen des BugFixes interessant sein kann: ICH würde mir einen MQTT Broker in einer VM installieren und zwischen 'geht' und 'geht nicht' hin und herschalten. Genau das hab ich gemacht . Wenn es dann allerdings einmal funktioniert, heißt das nicht unbedingt, dass das Problem wirklich gelöst ist....

[gunterc]

Bin leider auf noch ein Fragezeichen gestoßen:
Ich habe den Eindruck, dass bei den Kanälen was schief geht. Jedenfalls passt das, was ich im WebUI sehe nicht zu dem, was ich in MQTT sehe.

Im WebUI:

und das in MQTT:

Code: Alles auswählen

001158A98F226F TerrasseMarkise
▼0
ACTUAL_TEMPERATURE = {"ts":1586860341920,"v":18,"s":0}
ACTUAL_TEMPERATURE_STATUS = {"ts":1586860341920,"v":0,"s":0}
ERROR_CODE = {"ts":1586860341920,"v":0,"s":0}
CONFIG_PENDING = {"ts":1586860342068,"v":false,"s":0}
RSSI_DEVICE = {"ts":1586860342071,"v":-58,"s":0}
DUTY_CYCLE = {"ts":1586860342072,"v":false,"s":0}
UNREACH = {"ts":1586860342072,"v":false,"s":0}
ERROR_OVERHEAT = {"ts":1586860341920,"v":false,"s":0}
▼3
LEVEL = {"ts":1586860341767,"v":1,"s":0}
LEVEL_STATUS = {"ts":1586860341767,"v":0,"s":0}
SECTION = {"ts":1586860341767,"v":15,"s":0}
PROCESS = {"ts":1586860341767,"v":0,"s":0}
ACTIVITY_STATE = {"ts":1586860341767,"v":3,"s":0}
▼4
ACTIVITY_STATE = {"ts":1586860341785,"v":3,"s":0}
LEVEL = {"ts":1586860341785,"v":1,"s":0}
LEVEL_STATUS = {"ts":1586860341785,"v":0,"s":0}
SECTION = {"ts":1586860341785,"v":4,"s":0}
PROCESS = {"ts":1586860341785,"v":0,"s":0}
▼5
PROCESS = {"ts":1586860341796,"v":0,"s":0}
ACTIVITY_STATE = {"ts":1586860341796,"v":3,"s":0}
LEVEL = {"ts":1586860341796,"v":0,"s":0}
LEVEL_STATUS = {"ts":1586860341796,"v":0,"s":0}
SECTION = {"ts":1586860341796,"v":0,"s":0}
▼6
LEVEL = {"ts":1586860341807,"v":0,"s":0}
LEVEL_STATUS = {"ts":1586860341807,"v":0,"s":0}
SECTION = {"ts":1586860341807,"v":0,"s":0}
PROCESS = {"ts":1586860341807,"v":0,"s":0}
ACTIVITY_STATE = {"ts":1586860341807,"v":3,"s":0}
▼7
WEEK_PROGRAM_CHANNEL_LOCKS = {"ts":1586860342082,"v":0,"s":0}

Hast Du dafür eine Erklärung? Eigentlich kann doch MQTT nicht mehr und andere Kanäle sehen, als die CCU.

Ich verwende aktuell eine etwas komplexere Konstellation mit RPi und CCU-Jack, Docker MQTT-Bridge und Docker Node-Red, beide auf einem Desktop. Wenn es hilft kann ich das gerne auch abspecken...

[Black]

doch das passt schon.... :5 und :6 sind 2 virtuelle kanäle des Schaltaktors.

was du in der WebUI siehst sind immer noch dinge die du auch sehen sollst. Mit Scripten, Addons wie diesem, oder auch Tools wie dem SDV kann man einer CCU auch unter den Mantel schauen^^

die Kanäle würdest du aber auch sehen, wenn du die Kindersicherung ausschaltest ^^

Black

[gunterc]

OK. Das hat man schon mal. An anderer Stelle läuft das unter 'Versteckte Funktion' o.Ä.

Was mich jetzt noch interessiert ist, wie das andersherum ist: MQTT zeigt weniger an (2 Kanäle) , als das WebUI (8 Kanäle:

Code: Alles auswählen

000A18A9970092  WohnHeizung
▼0
RSSI_DEVICE = {"ts":1586859901092,"v":-50,"s":0}
OPERATING_VOLTAGE_STATUS = {"ts":1586859901092,"v":0,"s":0}
OPERATING_VOLTAGE = {"ts":1586859901092,"v":2.6,"s":0}
CONFIG_PENDING = {"ts":1586859901091,"v":false,"s":0}
DUTY_CYCLE = {"ts":1586859901092,"v":false,"s":0}
LOW_BAT = {"ts":1586859901092,"v":false,"s":0}
UNREACH = {"ts":1586859901092,"v":false,"s":0}
▼1
ACTUAL_TEMPERATURE = {"ts":1586859901109,"v":21.1,"s":0}
BOOST_MODE = {"ts":1586859901109,"v":false,"s":0}
SET_POINT_TEMPERATURE = {"ts":1586859901107,"v":20,"s":0}
LEVEL_STATUS = {"ts":1586859901108,"v":0,"s":0}
WINDOW_STATE = {"ts":1586859901109,"v":0,"s":0}
BOOST_TIME = {"ts":1586859901107,"v":0,"s":0}
FROST_PROTECTION = {"ts":1586859901108,"v":false,"s":0}
VALVE_STATE = {"ts":1586859901108,"v":4,"s":0}
ACTIVE_PROFILE = {"ts":1586859901108,"v":1,"s":0}
LEVEL = {"ts":1586859901108,"v":0.24,"s":0}
ACTUAL_TEMPERATURE_STATUS = {"ts":1586859901108,"v":0,"s":0}
SWITCH_POINT_OCCURED = {"ts":1586859901108,"v":false,"s":0}
PARTY_MODE = {"ts":1586859901108,"v":false,"s":0}
QUICK_VETO_TIME = {"ts":1586859901108,"v":0,"s":0}
SET_POINT_MODE = {"ts":1586859901108,"v":0,"s":0}

[Black]

Das wird daran liegen, das diese Kanäle nur in DV´s genutzt werden und keine Datenpunkte haben-

Black