CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter

[ptweety]

Generell wird die Erkundung nicht auf einem Schlag ausgeführt, da dies die ReGaHss zu lange blockiert. Der CCU-Jack geht sanft mit der ReGaHss um und macht nur kleine Anfragen mit Pausen dazwischen.

Ah, danke dafür. Ich meinte aber etwas anderes ... aus Sicht eines VEAP-Clients gedacht oder allgemein eines Users, welcher eine Gesamtsicht aller Geräte mit deren Kanälen, Datenpunkten und den jeweiligen Eigenschaften auslesen will.

Also eigentlich folgende UseCases:

• Ich brauche eine Information über alle Geräte und deren Kanäle, Datenpunkte, Parametern
• Ich brauche eine Information über alle neuen / geänderten / gelöschten Geräte, Kanäle, Datenpunkte, Parameter, ...

Wozu sollte das Gut sein:

1. Ich möchte per MQTT etwas vom CCU-Jack abonnieren und vorab die Möglichkeiten in meinem VEAP-Client erkunden (also das, was Alexa weiter oben vorgestellt hat)
2. Ich möchte per MQTT empfangene Nachrichten mit zusätzlichen Informationen zum Gerät, Kanal, Datenpunkt und deren Parametern anreichern

Ein Beispiel zu A.: eine einzelne Abfrage eines Gerätes ergibt einen vollständigen Baum mit allen Details, die man auch über die "~links" erkunden kann:

Code: Alles auswählen

[
  {
    "address": "00xxxxxxxxxxxx",
    "aesActive": 1,
    "availableFirmware": "0.0.0",
    "children": [
      "00xxxxxxxxxxxx:0"
    ],
    "direction": 0,
    "firmware": "4.4.12",
    "flags": 9,
    "group": "",
    "identifier": "00xxxxxxxxxxxx",
    "index": 0,
    "interface": "",
    "interfaceType": "HmIP-RF",
    "linkSourceRoles": "",
    "linkTargetRoles": "",
    "paramsets": [
      "MASTER",
      "SERVICE"
    ],
    "parent": "",
    "parentType": "",
    "rfAddress": 12149557,
    "roaming": 0,
    "rxMode": 0,
    "team": "",
    "teamChannels": null,
    "teamTag": "",
    "title": "HmIP-CCU3 Funkmodul",
    "type": "HmIP-CCU3",
    "version": 2,
    "~links": [
      {
        "rel": "channel",
        "href": "0",
        "title": "HmIP-CCU3 Funkmodul:0"
      }
    ],
    "channels": [
      {
        "address": "00xxxxxxxxxxxx:0",
        "aesActive": 1,
        "availableFirmware": "",
        "children": null,
        "direction": 0,
        "firmware": "",
        "flags": 1,
        "group": "",
        "identifier": "0",
        "index": 0,
        "interface": "",
        "linkSourceRoles": "",
        "linkTargetRoles": "",
        "paramsets": [
          "MASTER",
          "VALUES",
          "SERVICE"
        ],
        "parent": "00xxxxxxxxxxxx",
        "parentType": "HmIP-CCU3",
        "rfAddress": 0,
        "roaming": 0,
        "rxMode": 0,
        "team": "",
        "teamChannels": null,
        "teamTag": "",
        "title": "HmIP-CCU3 Funkmodul:0",
        "type": "MAINTENANCE",
        "version": 2,
        "~links": [
          {
            "rel": "parameter",
            "href": "INCLUSION_UNSUPPORTED_DEVICE",
            "title": "HmIP-CCU3 Funkmodul:0 - INCLUSION_UNSUPPORTED_DEVICE"
          },
          {
            "rel": "parameter",
            "href": "CARRIER_SENSE_LEVEL",
            "title": "HmIP-CCU3 Funkmodul:0 - CARRIER_SENSE_LEVEL"
          },
          {
            "rel": "parameter",
            "href": "DUTY_CYCLE_LEVEL",
            "title": "HmIP-CCU3 Funkmodul:0 - DUTY_CYCLE_LEVEL"
          },
          {
            "rel": "parameter",
            "href": "$MASTER",
            "title": "HmIP-CCU3 Funkmodul:0 - $MASTER"
          },
          {
            "rel": "device",
            "href": "..",
            "title": "HmIP-CCU3 Funkmodul"
          }
        ],
        "datapoints": [
          {
            "rel": "parameter",
            "href": "INCLUSION_UNSUPPORTED_DEVICE",
            "title": "HmIP-CCU3 Funkmodul:0 - INCLUSION_UNSUPPORTED_DEVICE"
          },
          {
            "rel": "parameter",
            "href": "CARRIER_SENSE_LEVEL",
            "title": "HmIP-CCU3 Funkmodul:0 - CARRIER_SENSE_LEVEL"
          },
          {
            "rel": "parameter",
            "href": "DUTY_CYCLE_LEVEL",
            "title": "HmIP-CCU3 Funkmodul:0 - DUTY_CYCLE_LEVEL"
          }
        ],
        "rooms": [],
        "functions": []
      }
    ]
  },
  ...
]

Ein Beispiel zu B.: aus folgender MQTT-Nachricht:

Code: Alles auswählen

{
  "topic": "device/status/00xxxxxxxxxxxx/0/DUTY_CYCLE_LEVEL",
  "payload": {
    "ts": 1643870598057,
    "v": 20,
    "s": 0
  },
  "qos": 1,
  "retain": true
}

möchte ich eigentlich folgende machen:

Code: Alles auswählen

{
  "topic": "device/status/00xxxxxxxxxxxx/0/DUTY_CYCLE_LEVEL",
  "payload": 20,
  "iface": "HmIP-RF",
  "device": "00xxxxxxxxxxxx",
  "deviceName": "HmIP-CCU3 Funkmodul",
  "deviceType": "HmIP-CCU3",
  "channel": "00xxxxxxxxxxxx:0",
  "channelName": "HmIP-CCU3 Funkmodul:0",
  "channelType": "MAINTENANCE",
  "channelIndex": 0,
  "datapoint": "DUTY_CYCLE_LEVEL",
  "datapointName": "HmIP-RF.00xxxxxxxxxxxx:0.DUTY_CYCLE_LEVEL",
  "rooms": [],
  "functions": [],
  "qos": 1,
  "retain": true,
  "ts": 1643870598057,
  "uncertain": true
}

[Alexandra]

Servus,

die Information ist doch im Navigator sauber vorhanden - wenn du die jedesmal bei einer Statusänderung mitschickst blähst du den MQTT doch unheimlich auf, oder?
Die Trennung von Struktur und Daten wäre somit auch durchbrochen.

• Ich brauche eine Information über alle Geräte und deren Kanäle, Datenpunkte, Parametern
• Ich brauche eine Information über alle neuen / geänderten / gelöschten Geräte, Kanäle, Datenpunkte, Parameter, ...

Die geänderten Strukturdaten würdest du ja durch das angesprochene Polling der Rega zur Verfügung bekommen?

Mit lieben Grüßen, Alexa

[ptweety]

Hi Alexa,

die Information ist doch im Navigator sauber vorhanden

Korrekt. Aber es geht mir nicht um den Navigator vom CCU-Jack, sondern um einen externen VEAP-Client, welcher mit dem VEAP-Server, also CCU-Jack verbunden ist. Dieser externe Client muss derzeit rekursiv durch alle Elemente des Root Endpunktes vom CCU-Jack durchgehen, damit er eine Kopie der Baumstruktur erhalten kann.

Also bei meinem obigen Beispiel wird gesucht und letztlich mein HmIP-CCU3 Funkmodul:0 - DUTY_CYCLE_LEVEL erkundet. Dazu muss der VEAP-Client zuerst mal die Geräte (/device) erkunden, dort das Gerät raussuchen (/device/00xxxxxxxxxxxx) und nach dem Kanal (/device/00xxxxxxxxxxxx/0) fragen, um letztlich die Parameter von /device/00xxxxxxxxxxxx/0/DUTY_CYCLE_LEVEL zu lernen. Da steht dann maximum = 100, minimum = 0, typ = FLOAT und unit = %

Wenn nun z.B. 4 Geräte mit jeweils 5 Kanälen und wiederum jeweils 6 Datenpunkten und wiederum 7 Parametern im CCU-Jack existieren, dann braucht man zur vollständigen Erkundung 4 * 5 * 6 * 7 = 840 Aufrufe gegen den CCU-Jack. Sind es dann aber 400 Geräte, so bist du bei 84.000 Aufrufen. Autsch

wenn du die jedesmal bei einer Statusänderung mitschickst blähst du den MQTT doch unheimlich auf, oder?

Damit genau das nicht passiert, also CCU-Jack nicht bei jeder MQTT Nachricht alle möglichen Informationen mitliefern muss, sollte ein VEAP-Client, welcher auch gleichzeitig ein MQTT-Clent ist, eben unabhängig vom CCU-Jack eine Kopie der Struktur-Daten halten können und aus dieser Kopie dann die Anreicherung der MQTT Nachricht selber vornehmen.

[Alexandra]

War mir unheimlich gefallen hat war folgende Aussage:

Generell wird die Erkundung nicht auf einem Schlag ausgeführt, da dies die ReGaHss zu lange blockiert. Der CCU-Jack geht sanft mit der ReGaHss um und macht nur kleine Anfragen mit Pausen dazwischen.

Wir fahren ein System mit rund 400 HmIP Geräten und der DutyCycle ist an guten Tagen sogar unter 70%. Somit favorisiere ich klar einen Ansatz der ressourcenschonend mit den Systemen umgeht.

Eine nette Idee wäre allerdings am Device selbst die entsprechenden Attribute anzuhängen, also

Code: Alles auswählen

DEVICE 0123455 <-- DEM hier die Attribute als JSON anzuhängen.
    - Attribute {iface": "HmIP-RF," "deviceType": "HmIP-SMI55", "name": "OG_Buero_Bewegung" }
    - Kanal1
    - MOTION
    - ILLUMINATION
    - ILLUMINATION_STATE
  - Kanal0
    - CONFIG_PENDING
    - UNREACH

Änderung nicht bei jeder Wertänderung eines Datenpunktes sondern Update beim RegaPoll.

Da ist die Frage wie hoch der Aufwand dafür wäre und ob das im Sinne des Erfinders ist?
Fällt aber klar unter Feature-Request der sauber durchdacht gehört bevor er eingekippt wird.

Mit lieben Grüßen, Alexa

[Mathias]

Ich habe mal Eure Ideen zusammengefasst und ein Issue erstellt.

[DJDieter]

Hallo Zusammen.

Ich nutze seit zwei Tagen den CCU-Jack. Nach anfänglichen Startschwierigkeiten klappts jetzt. Erstmal ein Kompliment: geniales Teil.

Jetzt bin ich aber schon an meine Grenzen oder die des CCU-Jack gestoßen. Ich lese mittels "virtuellen Geräten" meinen Mähroboter aus. Da dieser aber nicht nur Zahlen, sondern auch Wörter sendet, geht das mit den virtuellen Geräten nicht mehr.

Ist es irgendwie möglich, bestimmte Topics des Mähers (die mit Wörtern) auszulesen und in eine Systemvariable zu schreiben? Wenn ja, wie?

Ich bin kein großartiger Programmierer und kenne MQTT erst seit zwei Tagen.


Schon mal vielen Dank und schönen Abend
Dieter

[Mathias]

Ist es irgendwie möglich, bestimmte Topics des Mähers (die mit Wörtern) auszulesen und in eine Systemvariable zu schreiben? Wenn ja, wie?

Wenn es ein bestimmter Satz an Wörtern ist, kannst Du für je zwei Wörter ein "MQTT Empfangstaster" anlegen. Alle Empfangstaster werden mit demselben TOPIC konfiguriert und unterschiedlichen PATTERNs. Dann hast Du die Ereignisse schonmal in der CCU. Bei Bedarf kannst Du dann auf Basis der Ereignisse eine Systemvariable setzen.

Gruß
Mathias

[DJDieter]

Vielen Dank für den Tipp. Werde ich so mal probieren.

[ecky78]

Hallo zusammen, ich habe bei meiner frischen CCUJack-Installation einen Fehler im Log: "Retrieving of progams from CCU failed: Retrieving programs: Invalid response line: 9555" gefolgt vom Namen des Programms. Dieses funktioniert aber, sodaß ich mich jetzt frage, wie ich herausfinden kann, was da nicht stimmt. Wie kann ich das herausfinden? Der Hinweis auf die Programmzeile hilft mir erstmal nicht weiter

[Mathias]

Bitte mal eine detaillierte Log-Datei erstellen und per PN schicken:

• In der Web-UI des CCU-Jacks Logging auf TRACE stellen.
• CCU-Jack oder CCU neu starten, damit die Programme nochmals erkundet werden.
• Log-Datei /var/log/ccu-jack.log von der CCU herunter kopieren. Z.B. mit WinSCP, vorher SSH auf der CCU aktivieren.
• In der Web-UI des CCU-Jacks Logging wieder auf INFO stellen.

Weitere Informationen zum CCU Dateitransfer.