search

danielwippermann / resol-vbus

A JavaScript library for processing RESOL VBus data
MIT License
67 stars 34 forks source link

2 Geräte auf dem VBus verursachen Probleme #106

Open StefanR71 opened 1 month ago

StefanR71 commented 1 month ago

Hallo,

ich habe hier 2 Steuerungen:

Vitosol 200 DeltaTherm HC Max

Angebunden habe ich diese über einen LAN Adapter. Im LAN Adapter sind 2 VBus Klemmen, an jeder habe ich eine Steuerung angeschlossen.

Aus den Beispielen habe ich den json-live-data-server eingerichtet. Zuerst hat alles wunderbar funktioniert. Ich konnte von beiden Steuerungen die Werte abfragen.

Dann nach einem Reboot des Linus Servers wurde von der HC Max plötzlich nicht mehr alles ausgelesen, der gesamte 1711_10_0100 Bereich mit den Sensoren fehlte.

Ich habe diverse Neustarts aller Komponenten gemacht aber ich habe es nicht stabil ans laufen bekommen.

Da ich zuvor die Geräte mit einem Python Script abgefragt hatte und dieses nicht mit 2 Geräten auf dem VBUS klargekommen ist habe ich 2 LAN Adapter hier. Also wieder jede Steuerung an einen LAN Adapter angeschlossen und die index.js und die config so modifiziert, dass ich 2 dieser Server parallel betreiben kann. Nun läuft einer auf dem Port 3333 und einer auf 4444.

Bis jetzt funktioniert das ganze stabil.

Habe ich da bei den 2 Geräten auf dem VBus etwas falsch gemacht oder hat die Software da evtl. ein Problem?

Viele Grüße Stefan

danielwippermann commented 1 month ago

Hi Stefan!

Sowohl die Vitosolic 200 als auch der DeltaTherm HC MAX sind VBus-Master-Geräte. Beide zeichnet damit aus, dass sie:

Die beiden Klemmenpaare des VBus/LAN-Adapters sind meines Wissens nach direkt miteinander verbunden. Als Du nun beide Regler an den selben VBus/LAN-Adapter angeschlossen hast, sind sich die beiden Regler "in die Quere" gekommen, weil der VBus keine Kollisionsvermeidung hat. Denn beide senden im Takt von einigen Sekunden ihre Daten und da ist die Gefahr groß, dass sich die Daten dabei gegenseitig so beeinflussen, dass Du als Empfänger am LAN-Anschluss viele fehlerhafte, nicht mehr VBus-Protokoll-konforme Daten bekommst.

Jedem Regler einen eigenen VBus/LAN-Adapter zu geben, ist daher notwendig und sinnvoll.

Bis dann, Daniel

StefanR71 commented 1 month ago

Moin Daniel,

viel Dank für die Infos, das erklärt natürlich alles. Ich hatte in den Spezifikationen nur gelesen, dass der VBus wie der Modbus mit Master/Slave arbeitet und das mehrere Slave auf dem Bus sein können. Aber wer hier Master und wer Slave ist, habe ich so nicht gefunden. Ich hatte einfach angenommen, der Master fragt den Slave ab.

Okay, dann habe ich ja nun alles korrekt gemacht und kann es so lassen.

Viele Grüße Stefan

StefanR71 commented 1 month ago

Ich habe auch gerade noch mal mit dem Resol Support telefoniert, die beiden klemmen sind in der Tat einfach nur parallel. Erst beim DL2 Plus, wo das wirklich identisch aussieht, sind es dann auch 2 Kanäle. Denn ich war etwas irritiert, da in dem Handbuch zum LAN Adapter nur eine Klemme abgebildet ist...

Wenn ich das korrekt gelesen habe, dann bräuchte ich beim DL2 Plus keinen extra json Server mehr, da könnte ich diese Infos direkt aus dem Gerät per HTTP abfragen... Weil das würde dann die Umgebung hier vom Aufbau dann noch mal etwas vereinfachen...

Viele Grüße Stefan

danielwippermann commented 1 month ago

Huhu Stefan,

ja, richtig. Bei Verwendung eines DL2 Plus kannst Du Dir die aktuellen Live-Daten als JSON-Format mit zwei HTTP-POST-Requests abholen:

Wenn Du das Ausloggen weglässt, kannst Du die "authId" wiederverwenden, sie ist allerdings nur begrenzte Zeit gültig und irgendwann wirst Du gezwungen sein, den ersten Request zu wiederholen.

Das zurückgegebene JSON-Format ist in etwa das, was auch beim DL2 / DL3 verwendet wird:

https://danielwippermann.github.io/resol-vbus/#/md/docs/dlx-data-download-api

Wenn Du noch Rückfragen hast, melde Dich einfach nochmal!

Bis dann, Daniel

danielwippermann commented 1 month ago

Huhu Stefan,

nur um einen Eindruck zur Komplexität mit dem DL2 Plus zu vermitteln, hier mal die zwei POST-Requests, wie ich sie mit einem REST-Client mit {{xxx}}-Variablen-Ersetzung verschicke:

1) "authId" besorgen

POST http://{{IP}}/cgi-bin/resol-webservice
Content-Type: application/json

[{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "login",
    "params": {
        "username": "admin",
        "password": "{{PASSWORD}}"
    }
}]

Darauf gibt es dann eine pseudo-zufällige "authId" zurück:

HTTP/1.1 200 OK
Connection: close
Transfer-Encoding: chunked
Content-Type: application/json
Cache-Control: no-cache
Expires: 0

[
  {
    "jsonrpc": "2.0",
    "id": 1,
    "result": {
      "authId": "1cf7299460bd9c2d8d9a0778bc6448cb"
    }
  }
]

2) Daten besorgen und auslogggen

Die "authId" aus Schritt 1) setze ich dann hier ein:

POST http://{{IP}}/cgi-bin/resol-webservice
Content-Type: application/json

[{
    "jsonrpc": "2.0",
    "id": 2,
    "method": "dataGetCurrentData",
    "params": {
        "authId": "{{AUTHID}}"
    }
}, {
    "jsonrpc": "2.0",
    "id": 3,
    "method": "logout",
    "params": {
        "authId": "{{AUTHID}}"
    }
}]

Auf den Request bekommst Du dann die Live-Daten (und eine Bestätigung für das "logout") zurück:

HTTP/1.1 200 OK
Connection: close
Transfer-Encoding: chunked
Content-Type: application/json
Cache-Control: no-cache
Expires: 0

[
  {
    "jsonrpc": "2.0",
    "id": 2,
    "result": {
      "headers": [
        ...
      ],
      "headerset_stats": {
        "headerset_count": 1,
        "min_timestamp": 1729311498.6900001,
        "max_timestamp": 1729311498.6900001
      },
      "headersets": [
        {
          "timestamp": 1729311498.6900001,
          "packets": [
            ...
          ]
        }
      ]
    }
  },
  {
    "jsonrpc": "2.0",
    "id": 3,
    "result": {}
  }
]

Bis dann, Daniel

StefanR71 commented 1 month ago

Hallo Daniel,

danke für die Informationen, mein Vater hat das Teil mal beim Großhandel geordert, sollte Montag eintreffen.

Dann werde ich mal sehen ob ich das in einem Bash-Script hin bekomme. Wenn mir das zu komplex ist kann ich ja auch noch die Parameter über Modbus/TCP abfragen, damit frage ich hier schon einige andere Geräte ab.

Viele Grüße und ein schönes Wochenende! Stefan

PS: Wenn jemand 2 VBus LAN Adapter benötigt, ich habe da vermutlich 2 abzugeben. :-)

StefanR71 commented 1 month ago

Gerade etwas Zeit gehabt und schon mal auf der Web-Seite (dein Link oben) gelesen...

Ich mache das Monitoring ja über ein Bash-Script und da steht ja schon ein "curl" Kommando als Beispiel. Das ist ja alles was ich brauche, also alles kein Problem...

Viele Grüße Stefan

danielwippermann commented 1 month ago

Huhu Stefan,

ja, aber der curl-Befehl funktioniert nur mit den älteren DL2 / DL3, beim DL2 Plus wird er nicht gehen, weil man die Authentifizierungs-Infos nicht per als URL-Parameter mitgeben kann.

Bis dann, Daniel

StefanR71 commented 1 month ago

Hallo Daniel,

hm, schade, dann wohl doch eher Modbus/TCP da gibt es ein klasse Tool: https://github.com/favalex/modbus-cli

Ich werde testen und berichten...

Viele Grüße Stefan

StefanR71 commented 1 month ago

Hallo Daniel,

modbus scheidet auch aus, sowas blödes, denn im Handbuch steht:

Der an den Klemmen 1 und 2 angeschlossene Regler kann an eine Gebäudeleittechnik angebunden werden. Dafür steht eine Modbus- oder eine BACnet-Funktionalität zur Verfügung.

Die Klemmen 1 und 2 sind leider der Kanal 1 und die Klemmen 3 und 4 der Kanal 2.

Hätte man da nicht schreiben können Kanal 1, so kann es schnell zu Fehlinterpretationen kommen, da denkt man erstmal Klemme 1 Kanal 1 und Klemme 2 Kanal 2...

Sowas blödes, dann muss ich mich also doch mit den CGI abfragen auseinandersetzen...

Viele Grüße Stefan

StefanR71 commented 1 month ago

Hab's mit curl hinbekommen, 2 Kommandos hintereinander eingeben:

authid=$(curl -s -H 'Content-Type: application/json' -X POST "http://192.168.77.80/cgi-bin/resol-webservice" -d '{"jsonrpc": "2.0", "id": 1, "method": "login", "params": {"username": "admin", "password": "password"}}' | grep -o -P '.{0,0}"authId":.{0,90}' | grep -o -P '.{0,0}":.{0,90}' | sed 's/[^a-z0-9.]//g' )

curl -H 'Content-Type: application/json' -X POST "http://192.168.77.80/cgi-bin/resol-webservice" -d '{"jsonrpc": "2.0", "id": 2, "method": "dataGetCurrentData", "params": {"authId": "'$authid'"}}, {"jsonrpc": "2.0", "id": 3, "method": "logout", "params": {"authId": "'$authid'"}}'

Nach dem ersten habe ich nur die AuthID in der Variable und nutze diese dann im 2. Kommando...

Viele Grüße Stefan

StefanR71 commented 1 month ago

Okay, eine Kleinigkeit fehlt mir gerade noch, wie kann ich die Ausgabe filtern? Es gibt da scheinbar diese Kommandos:

dataGetFilters dataSetFilters dataGetFilterData dataSetFilterData

mit:

curl -s -H 'Content-Type: application/json' -X POST "http://192.168.77.80/cgi-bin/resol-webservice" -d '{"jsonrpc": "2.0", "id": 2, "method": "dataGetFilterData", "params": {"filterId": "00", "authId": "'$authid'"}}' | jq

Kann ich mir meinen konfigurierten Filter anzeigen lassen. Mit dataSetFilters zweschieße ich meinen Filter und bei dataSetFilterData passiert irgendwie nichts.

Ich dachte ich müsste irgendwie vorher den Filter auswählen, denn einfach nur:

curl -s -H 'Content-Type: application/json' -X POST "http://192.168.77.80/cgi-bin/resol-webservice" -d '{"jsonrpc": "2.0", "id": 2, "method": "dataGetCurrentData", "params": {"filterId": "00", "authId": "'$authid'"}}' | jq

nutzt auch nicht den Filter...

Viele Grüße Stefan

danielwippermann commented 1 month ago

Hi Stefan,

ja, leider unterstützt der dataGetCurrentData-Befehl keine Filterung. Die wird mittlerweile nämlich clientseitig im Browser gemacht und nicht mehr vom DL2 Plus vorgefiltert.

Das sieht man auch ganz gut, wenn man einen Filter einrichtet, dann die Ansicht des Filters öffnet und in der Entwicklerkonsole des Browsers mal den Netzwerk-Verkehr beobachtet. Da wird nur einmal die Filter-Daten geladen und danach zyklisch die VBus-Binärdatei, die dann vom Browser verarbeitet wird.

Bis dann, Daniel