Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[crycode]

@dreman Genau dafür ist diese Funktion gedacht, damit man eben nicht extra Scripte erstellen muss, um z.B. regelmäßig irgendwas abzufragen. :)
Einfach bei den entsprechenden Parsern aktivieren, Intervall und Wert festlegen und fertig. Um Abfragen zu Triggern wird der Wert wahrscheinlich true (bzw. Haken gesetzt) sein.

[Dreman]

@crycode Aber mit welcher Sequenz läuft das dann in der Praxis ab? Werden die Sendeframes in einer bestimmten Reihenfolge aktiviert, wird eine Antwort abgewartet, bevor die nächste Abfrage gestartet wird? Ich frage deshalb so dumm, weil das ganze bei mir nicht laufen will. Wenn ich Intervall und Wert nur bei einem Parser festlege (1 Minute), dann wird der Antwort-Wert sicher abgeholt. Setze ich jedoch Intervall und Wert auch bei einem weiteren Parser, dann funktioniert das beim 1. Parser nach wie vor, beim 2. Parser wird der Antwort-Wert aber meistens nicht abgeholt. Kann natürlich alles mit dem noch nicht völlig durchschauten CAN-Protokoll meiner Heizung zudammenhängen, aber mit manuellen Einzelabrufen der bisher bekannten Datenpunkte über das Terminal mit 'cansend can0 680#xxxxxxxx' werden unter der ID 690 im Adapter mit den entsprechenden Parser-Scripten die Antwort-Werte korrekt dargestellt.

[Dreman]

@crycode Alles zurück, funktioniert jetzt korrekt. Es handelt sich bei meiner Heizung um einen UDS Can-Bus und die Heizung beantwortet jede Anfrage mit einem Multiframe, erwartet also nach Empfang des 1. Frames eine Art Bestätigung (Flow Control, FC) und sendet erst dann weitere Frames mit Datenbytes (z.B. Einheit des Sensors ...). Wenn ich nun nach jeden Anforderungs-Parser einen FC-Parser einfüge, dann funktioniert das mit der minütlichen Abfrage ohne Probleme. Da die allermeisten Sensordaten bereits im ersten Antwort-Frame enthalten sind, klappt auch die Daten-Auswertung. Inwieweit es auch machbar ist, die Daten nach dem FC-Frame noch auszuwerten, ist derzeit für mich nur optional. Sorry für die Verwirrung.

[crycode]

@dreman Super!

Vlt. trotzdem noch zur Erklärung:
Beim Start des Adapters wird für alle Parser mit aktiviertem automatisch Senden intern ein Intervall gesetzt, der dann die Aktion regelmäßig triggert. Wenn mehrere Parser den gleichen Intervall haben, dann ist da letztendlich die Reihenfolge der Parser entscheidend. Heißt es wird erst der Parser getriggert, der in der Konfiguration ganz oben steht, dann der zweite usw.
Falls hier Bedarf besteht könnte ich da ggf. noch einen Offset oder sowas hinzufügen, dass die Parser mit einem definierbaren zeitlichen Versatz getriggert werden und man damit dann selbst bestimmen kann, was in welcher Reihenfolge gesendet wird.

Für deinen Anwendungsfall mit dem FC wäre es dann wahrscheinlich doch sinnvoll das in einem eigenen Script zu lösen.
Da kannst du dann die erste Anfrage starten, bei Antwort die Bestätigung senden, dann die zweite Anfrage Starten etc.
Ich würde in dem Fall dann wahrscheinlich erst der Reihe nach alle Daten abfragen und zum Schluss auswerten.

Falls du dazu Hilfe brauchst mach am besten einen neuen Thread auf und erwähne mich im Text, damit ich das auch mitbekomme.

Alternativ allgemeine Anfragen zum Adapter bitte am besten in den Thread [Adapter] CAN-Bus - Beschreibung, FAQ, Diskussionen, etc. ;)

[Dreman]

@crycode Danke für die Erklärung. Ich geb dir Recht, mit einem eigenen Script wäre die bessere und zuverlässigere Methode, denn mit dem internen Zeitablauf ist nach meinem Verständnis nicht sichergestellt, dass die geforderte Abfolge 'ASK-Frame schreiben' >> 'Antwort-Frame einlesen' >> 'FC-Frame schreiben' sicher eingehalten wird. Aber dazu muss man erstmal in der Lage sein, ein solches Script zu erstellen und da hakt es bei mir leider aus. Aber jetzt versuch ich erstmal, eine Lösung für das UDS Multiframe-Problem zu finden. Vielen Dank nochmal für dein hilfreiches Feedback.

[RaspiUser]

@cb187

Ich habe diesen Thread quer-gelesen und glaube, dass Du mir (wahrscheinlich, hoffentlich, vielleicht ...) helfen kannst:
Nachdem der Adapter nun sicher läuft und ich Zeit gefunden habe, mich mit der HPSU 516 zu beschäftigen, habe ich einige Anfänger-Fragen:

• Ist die Differenz zwischen "Energie Heizung fa06a7" und "Energie erzeugt fa0930" die erzeugte Wärmeenergie ?
• Welcher Wert ist bzgl. "Taktung" von Interesse?
• Was wären deine allgemeinen Empfehlung / Hinweise zur Optimierung ? Vielleicht Links zu anderen Foren ? Scripts ?

Danke für deine Antworten.

[cb187]

Wollte nur einmal kurz erwähnen, gehört zwar nicht in diesen thread aber wenn einer möchte kann ich eine Config Datei bereitstellen für einen ESP mit Caninterface um die Rolex abzufragen und zu steuern.
Das ganze wird auch in ESPHome bereitgestellt.
Bis jetzt werden die relevanten Sensoren abgefragt und der Betriebsmodus kann geändert werden.

[RaspiUser]

@cb187 sagte in Test Adapter canbus v1.1.x Latest:

gehört zwar nicht in diesen thread

... das hatte ich mir auch gedacht, als ich Dir meine Fragen stellte ...
Ich habe (noch) nix zur Heizungsoptimierung gefunden und hatte die Hoffnung, dass mit den Antworten der Einstieg dorthin klappen könnte ...

@cb187 sagte in Test Adapter canbus v1.1.x Latest:

ESP mit Caninterface um die Rolex

... keine neue Hardware (bin froh, dass bei mir jetzt alles Dank @crycode läuft ...) und eine neue Uhr brauche ich auch nicht ... :flushed: :grinning: (Spass .... was die Autokorrektur so macht ...)

EDIT:
... hier etwas zum Thema ... wer Interesse und (vor allem) Zeit hat ... :flushed:

[noio]

Hallo , ich bräuchte eure Hilfe !!!!
Ich kapiere das mit canbus.0.raw.received nicht.....
Ich möchte mit den rohen canbus Daten einzelner Datenpukte im JS Adapter arbeiten ....wie komme ich an diese ?
Vielen dank
Lg
noio

[crycode]

Hi @noio,

in den raw-States steht ein JSON-String, der die Daten enthält. Bei received ist das jeweils die zuletzt empfangene Nachricht.
Beispiel:

{"id":83902468,"ext":true,"data":[0,0,176,64,0,0,164,64]}

Diesen String kannst du mittels JSON.parse(derString) in ein Objekt umwandeln und dann auf id, ext und data Zugreifen.

• id ist die ID der CAN-Nachricht
• ext gibt an, ob die CAN-Nachricht im Extended Frame Format ist
• data ist ein Array mit den Daten-Bytes der CAN-Nachricht (0 bis 8 Byte)

Falls du die raw-Daten einer in der Adapterconfig angelegten Nachricht meinst, dann musst in dieser Nachricht auf den .json-State gehen (z.B. canbus.0.01004001.json). Der Enthält die Daten als JSON-Array.

[noio]

Super , Danke ...
Komisch...Leider kann ich die raw-States nicht finden.......der Haken ist gesetzt ........

Ja , die raw-Daten .... Doppel Danke.....bin gerade vorher drauf gestossen .......Anfänger halt (ich) ......

merci
Lg
noio

[crycode]

@noio sagte in Test Adapter canbus v1.1.x Latest:

Leider kann ich die raw-States nicht finden

Welche genau meinst du?

canbus.0.raw.received sollte da sein, sobald der Haken für die raw-States gesetzt ist.

canbus.0.01004001.json gibt es auch ohne aktivierte raw-States. Dafür muss aber zumindest eine Nachricht mit der ID (01004001 (hex) in dem Beispiel) in den Adaptereinstellungen angelegt sein. Parser brauchst du keine, wenn du direkt den .json State nutzen willst.

[noio]

@crycode sagte in Test Adapter canbus v1.1.x Latest:

canbus.0.raw.received sollte da sein, sobald der Haken für die raw-States gesetzt ist.

Ist beim mir aber nicht vorhanden ......

[crycode]

@noio muss aber eigentlich, wenn der Haken gesetzt ist.

Beim nächsten Start vom Adapter werden die States dann angelegt, bzw. gelöscht wenn der Haken nicht gesetzt ist.

Startet der Adapter denn korrekt, dass er grün wird?