Hallo zusammen,

heute möchte ich euch meinen neuen Adapter ioBroker.odl vorstellen und zum Testen einladen.

Der Adapter integriert die ODL (Ortsdosisleistung) Messwerte von ausgewählten Messstellen des Bundesamtes für Strahlenschutz (BfS) in ioBroker.

Damit ist für interessierte Personen einfach möglich, immer die aktuelle ODL in der eigenen Region im Blick zu behalten.

Aktuell ist der Adapter über das latest-Repository ober über GitHub (https://github.com/crycode-de/ioBroker.odl) verfügbar.

Das bundesweite Messnetz des BfS umfasst rund 1800 ortsfeste Messstellen, die permanent die vor Ort aktuelle Gamma-Umweltradioaktivität (Ortsdosisleistung) erfassen und aufzeichnen. Die gewonnenen Messdaten werden vom BfS gesammelt, ausgewertet und öffentlich unter der Datenlizenz Deutschland zur Verfügung gestellt.

Für weitere Informationen zur ODL siehe https://odlinfo.bfs.de/.

Dieser Adapter läd die aktuellen und historischen 1-Stunden-Mittelwerte der Messdaten direkt über einen Web Feature Service (WFS) des Geoportals des BfS. Das BfS ist Urheber der vom Adapter verwendeten Daten. Wird ein aktivierter History-Adapter (history, influxdb oder sql) erkannt, dann werden gegebenenfalls in der Historie fehlende Datenpunkte durch den Adapter automatisch nachgetragen, sodass sich vollständige Zeitreihen ergeben.

Die aktuellen Messdaten werden von dem Adapter standardmäßig im Stundentakt aktualisiert. Ein geringerer Aktualisierungsintervall ist meist nicht sinnvoll, da die zu Grunde liegenden Messdaten auf dem BfS-Server (abhängig von der Messstelle) größtenteils stündlich aktualisiert werden.

Viele Grüße

Hallo zusammen,
wie von @Ro75 bereits geschrieben liegt das Problem beim dem vom BfS verwendeten Zertifikat. Da scheint ein Teil der Zertifikatskette nicht mit ausgeliefert zu werden, wodurch das Zertifikat nicht geprüft werden kann.

Ich werde morgen eine Lösung des Problems in die Wege leiten.
Bis dahin bitte etwas Geduld.

Hallo zusammen,

ich habe den neuen Adapter DS18B20 erstellt.
Dieser Adapter bindet, beispielsweise auf einem Raspberry Pi, direkt die gleichnamigen 1-Wire Temperatursensoren in ioBroker ein.

Der Adapter ist in der Lage die gängigen Fehler des Sensors (Checksumme, 85°C, -127°C) zu erkennen und entsprechend zu reagieren (Logmeldungen, ggf. Null-Ersatzwerte).

Alle angeschlossenen Sensoren können über die Sensoren Suchen Funktion auch direkt automatisch erkannt werden.
Zudem ist es möglich für jeden einzelnen Sensor einen eigenen Abfrageintervall, einen Faktor und Offset, sowie die Anzahl der gewünschten Dezimalstellen anzugeben.

Weiterhin ist eine Verwendung in Skripten möglich.
Ein Skript kann das Lesen aller Sensoren oder eines bestimmten Sensors antriggern, einen Sensor direkt abfragen und die damit die aktuelle Temperatur erhalten oder nach verfügbaren (angeschlossenen) Sensoren suchen.

Eine Ausführliche Beschreibung ist im GitHub Repo zu finden.

Installiert werden kann der Adapter aktuell über das Latest-Repository, oder über den Link https://github.com/crycode-de/ioBroker.ds18b20.

Verbesserungsvorschläge und ggf. Bug-Meldungen sind gerne willkommen.

Viel Spaß beim Testen!

@buchi Genau, dein Adapter muss zuerst auf NPM veröffentlicht werden. Dafür brauchst du zuerst einmal einen npmjs.com Account.

Im test-and-release GitHub Workflow ist dann auch schon alles drin, was du für einen NPM-Release brauchst.
Siehe https://github.com/gerbuchner/ioBroker.vis-owl/blob/main/.github/workflows/test-and-release.yml#L31
Dort musst du letztendlich nur die Zeilen 36 bis 54 aktivieren (# am Anfang entfernen).
Auf npmjs.com legst du dir dann ein Access Token vom Typ Automation an. Dieses trägst du im GitHub Repo unter Secrets->Actions als NPM_TOKEN ein.

Wenn du dann einen Tag setzt, übernimmt die GitHub Action eigentlich alles und macht den NPM-Release für dich.

Zur Aufnahme in das Latest-Repo von ioBroker musst du deinen Adapter dann über einen PR bei https://github.com/ioBroker/ioBroker.repositories hinzufügen. Dort steht auch alles weitere, was dafür noch für Anforderungen existieren.

Der CAN-Bus (Controller Area Network) ist ein serielles Bussystem. Er kam ursprünglich vorrangig von Fahrzeugen zum Einsatz und ist inzwischen auch im Bereich der Heimautomatisierung recht verbreitet.

Dieser Adapter soll eine direkte Anbindung eines CAN-Interfaces (z.B. can0) an ioBroker ermöglichen.
Hierbei geht es um reine CAN-Nachrichten von bis zu 8 Byte Datenlänge. Aufgesetzte Protokolle wie z.B. CANOpen sind nicht vorgesehen.

Unterstützt wird jede Hardware, die sich auf einem Linux-basierten Betriebssystem als CAN-Interface meldet. Aufgrund der zugrundeliegenden socketcan Library werden Windows-Systeme leider nicht unterstützt.

Die Admin-Seite ist mit React auf Basis von adapter-react gebaut. Da dies noch recht neu ist, wären hier sicherlich auch ausgiebige Tests nicht verkehrt.

Dieser Adapter verwendet Sentry Libraries um automatisch Fehler an die Entwickler (mich) zu senden. Für mehr Details und Informationen zum Deaktivieren des Error-Reportings siehe Sentry-Plugin Dokumentation.

Features

• Empfangen und Senden von CAN-Nachrichten in Standard- und Extended-Frames
• Jede Nachricht kann einzeln zum Senden und/oder Empfangen konfiguriert werden
• Möglichkeit automatisch empfangene, aber noch nicht konfigurierte, CAN-Nachrichten hinzuzufügen
• Konfiguration von Parsern für die einzelnen CAN-Nachrichten zum Lesen/Schreiben von Daten von/in den Rohdaten-Buffer der Nachrichten
  • Zahlentypen
  • Boolsche Werte inkl. Bitmasken
  • Strings in verschieden Encodings
  • Eigene Scripte zum Lesen vom / Schreiben in den Buffer der Rohdaten
• Erweiterte Import/Export Funktionen
  • Import von Nachrichtenkonfigurationen zur Erweiterung der bestehenden Konfiguration
  • Import vor vordefinierten "bekannten" Konfigurationen von GitHub direkt im Admininterface
  • Export und Import der Nachrichtenkonfigurationen als json oder csv Dateien
• Optionale Verwendung der Datenlänge (DLC)
• Optionale Unterstützung des RTR-Flags
• Optionale Raw-States, welche die Rohdaten der empfangenen bzw. gesendeten/zu sendenden CAN-Nachrichten-Objekte beinhalten

Anforderungen

• Linux Betriebssystem
• CAN-Hardware, die vom Kernel unterstützt wird und ein Interface wie beispielsweise can0 bereitstellt
• Kenntnisse über die CAN-Nachrichten auf dem Bus (nicht zwingend erforderlich, aber hilfreich)

Parser

Über die Parser können Daten aus den Rohdaten einer CAN-Nachricht extrahiert bzw. in diese hineingeschrieben werden.

Es gibt vordefinierte Parser für die nachfolgend aufgeführten Datentypen und zusätzlich die Möglichkeit eigene Scripte zum Lesen/Schreiben zu erstellen.

Zahlentypen im Big-Endian und Little-Endian Format

• Signed und Unsigned 8, 16 und 32 Bit Integer
• 32 Bit Float
• 64 Bit Double

Boolsche Werte

• 1 Byte inkl. Unterstützung von Bitmasken

Strings

• 1 bis 8 Byte Länge
• Encodings: ascii, base64, hex, latin1, utf8, utf16le

Eigene Skripte
Beim Parsertyp Custom können eigene Skripte zum Lesen/Schreiben der Werte genutzt werden.
Diese Skripte laufen in einer Sandbox (ähnlich den Skripten vom JavaScript Adapter).

Folgende Features können in den Skripten genutzt werden:

• Die meisten Node.js Standardfunktionen
• async/await
• Log-Funktionen des Adapters: log.warn('something'), log.info('something'), log.debug('something')
• getStateAsync('id') und getObjectAsync('id'), wobei id die vollständige ID des States/Objektes ist

Fehler in den Skripten werden vom Adapter abgefangen und ins Log geschrieben.

In beiden Skripen sind die Variablen value und buffer vordefiniert. buffer enthält dabei jeweils die aktuellen Rohdaten der CAN-Nachricht als Node.js Buffer. value sollte beim Lesen auf den gelesenen Wert gesetzt werden. Beim Schreiben enthält value den zu schreibenden Wert.

Screenshots

Schlusswort

Die Übersetzungen sollten in Deutsch und Englisch vollständig und korrekt sein.
Übersetzungen für andere Sprachen sind teils automatisch übersetzt und teils noch gar nicht vorhanden. Wer mag kann gerne über Weblate die Übersetzungen vervollständigen/korrigieren.

Viel Spaß beim Testen!
Ich freue mich auf Feedback.

Grüße
Peter

Changelog

• Node.js 16.4+, js-controller 4+ und admin 6+ sind erforderlich
• Konfiguration der Sensoren wird nun anders gespeichert
• Neue Admin UI mit JsonConfig
• Wenn Remote-Sensoren verwendet werden, muss im Admin ein neuer Schlüssel dafür festgelegt werden
• read und readNow Aktionen zusammengefasst
• Neuer State info.remotesConnected mit einer Liste der verbundenen Remote-Systeme (wenn aktiviert)
• Icons für den Sensorstatus zu den Sensorobjekten hinzugefügt
• Markierung von Objekten von deaktivierten Sensoren
• Löschen von Objekten von unkonfigurierten/gelöschten Sensoren
• Aktualisierte Übersetzungen
• Codeoptimierungen und Upgrades auf aktuelle Standards
• Aktualisierte Abhängigkeiten
• Kompatibilität mit js-controller 5 ab v2.0.4

Wichtig

Ab Version 2.0.0 wird die Konfiguration der einzelnen Sensoren anders gespeichert und die Sensor-Objekte werden anders angelegt.
Beim ersten Start mit Version >=2.0.0 wird die alte Konfiguration zum neuen Schema migriert und der Adapter startet anschließend neu. Dabei sollten alle Sensor-spezifischen Einstellungen erhalten bleiben.

Wenn Remote-Sensoren verwendet werden, muss im Admin ein neuer Schlüssel dafür festgelegt werden!
Dieser Schlüssel muss natürlich dann auch in der Config der Remote-Systeme eingetragen werden.

Was ist besonders zu testen?

• Beim Upgrade von v1.x auf 2.x sollte eine Meldung im Admin angezeigt werden
• Klappt die Migration der Konfiguration?
• Werden die Sensor-Objekte korrekt angelegt?
• Admin UI:
  • Funktionieren alle Eingaben etc. und ist alles leicht verständlich?
• Nutzung in Scripten:
  • Die Aktionen read und readNow wurden zusammengefasst und erweitert. Alte Scripte sollten weiterhin problemlos mit beiden funktionieren. Neue Scripte können mehr Infos erhalten. Details in der Doku.

@stoffel67 Ist ein Bug im Admin, der nur bei einer speziellen Konstellation in der JsonConfig auftritt.
Ich habe einen Issue dazu erstellt: https://github.com/ioBroker/ioBroker.admin/issues/2527

Als Workaround könntest du eine ältere Version von Admin (vor 16.17.0) installieren.

crycode-de created this issue in ioBroker/ioBroker.admin

closed [bug]: null values in jsonConfig breaks adapter config page #2527

Hallo,

wenn ich das richtig verstehe, dann sollte das also für einen Adapter, der Daten z.B. stündlich von einer öffentlichen Webschnittstelle abruft, so aussehen:

"common": {
  [...]
  "connectionType": "cloud",
  "dataSource": "poll",
  [...]
}

Oder ist mit connectionType: "cloud" nur die Verbindung zur ioBroker Cloud gemeint?

@fastfoot Ich denke das Problem hier ist, dass .forEach für jedes Element im Array die angegebene Callback-Funktion aufruft, aber nicht auf die asynchrone Fertigstellung wartet.

Du kannst dein Array einfach mit for (let key of statesToCreate) { ... } durchlaufen. Dann sollte es klappen.

Hallo liebe ioBroker-Gemeinde,

ich habe einen neuen Adapter zur Integration von RadioHead (Funk-) Netzwerken in ioBroker erstellt.

Die Kommunikation erfolgt über eine serielle Schnittstelle. Zur Anbindung von Funk-Hardware kann ein kleiner Mikroprozessor (z.B. ein Arduino Nano) als Gateway verwendet werden.

Hintergrund

RadioHead ist eine Open Source paketbasierte Funkmodul-Bibliothek für Mikroprozessoren. Es bietet adressierte, zuverlässige, wiederholt übertragene und bestätigte Nachrichten in variabler Länge.
Ich nutze es unter anderem für eine bidirektionale Funkverbindung zwischen einem selbst entwickelten automatischen Bewässerungssystem für das heimische Gewächshaus und der Zentrale meiner Heimautomatisierung.

Für die Anbindung der Funkhardware an einen Rechner wird ein Serial-Radio-Gateway benötigt. Dies ist im einfachsten Fall ein Arduino Nano mit den entsprechenden Funkmodulen und einem kleinen Sketch, der die Pakete zwischen und Funk und der seriellen Schnittstelle hin und her reicht. (Beispielsketch)

Features

• Empfang von Nachrichten/Befehlen von anderen Knoten im RadioHead-Netzwerk.
• Senden von Nachrichten/Befehlen an andere Knoten im RadioHead-Netzwerk.
• Einzeln konfigurierbare Objekte für eingehende und ausgehende Daten.
• Möglichkeit RadioHead-Nachrichten über Skripte zu senden.
• Möglichkeit empfangene RadioHead-Nachrichten über Skripte auszuwerten.

Wird über die serielle Schnittstelle eine Nachricht empfangen, die zum Muster eines Objektes der eingehenden Daten passt, so werden die Daten daraus extrahiert und von dem Adapter in den State des Objektes geschrieben.

Zum Senden von Daten werden die Daten einfach in den State des konfigurierten Objektes der ausgehenden Daten geschrieben und der Adapter sendet dann die Daten nach dem eingestellten Muster.

Installation

Der Adapter ist aktuell über das latest-Repository verfügbar.

Alternativ kann er über die URL https://github.com/crycode-de/ioBroker.radiohead.git installiert werden.

Beschreibung

Eine vollständige und umfangreiche Beschreibung inklusive Erklärungen zu den einzelnen Konfigurationsmöglichkeiten ist hier zu finden.

Aufgrund der unterschiedlichsten Daten, die mit einer RadioHead-Nachricht empfangen oder gesendet werden können, ist die Konfiguration so flexibel wie möglich aufgebaut und wirkt auf den ersten Blick vielleicht auch etwas komplex.

Je nach Konfiguration werden die einzelnen Objekte unter radiohead.<instanz>.data.<in|out>.<name> automatisch erstellt. Bei Objekten für eingehende Daten wird der State entsprechend aktualisiert, sobald eine passende RadioHead-Nachricht empfangen wurde. Bei Objekten für ausgehende Daten kann der neue State in das Objekt geschrieben werden und der Adapter sendet daraufhin die entsprechende RadioHead-Nachricht.

Über radiohead.<instanz>.info.* werden zu dem ein paar allgemeine Informationen zur Verfügung gestellt.

Screenshots

Verbesserungsvorschläge und ggf. Bug-Meldungen sind gerne willkommen.

Viel Spaß beim Testen!

@elektroniker86 sagte in Rotex HPSU / Daikin Altherma Wärmepumpe über ioBroker.canbus:

Welche Konfigurationsversion soll ich installieren latest, 1.8 oder die 301 latest?

Zusammen mit Adapterversion 2.1.1 am besten die latest-Config. Damit sollten auch die Meldungen im Log weg sein.

@elektroniker86 sagte in Rotex HPSU / Daikin Altherma Wärmepumpe über ioBroker.canbus:

Die beiden Einträger kamen erst nachdem ich den Adapter platt gemacht habe.

Ich schätze mal, du hattest vorher die Option "Gesehene Nachrichten automatisch hinzufügen" nicht aktiv. Die kann eigentlich auch getrost aus in dem Fall.

@elektroniker86 sagte in Rotex HPSU / Daikin Altherma Wärmepumpe über ioBroker.canbus:

2024-11-30 12:29:45.002	warn	Failed parsing JSON from canbus.0.680.json: No state found

Also wenn die Meldung nach der Installation bzw. ein Einrichten ein Mal kommt ist das ok, weil da beim ersten Abfragen oder Setzen erst der State geschrieben wird und der vorher nicht gesetzt ist. Anschließend sollte die Meldung nicht mehr kommen.

Was komisch ist das bei den Instanzeinstellungen bei nicht konfigurierte Nachrichten 2 Einträge sind.

Also die 10A sind CAN-Nachrichten von der RoCon Einheit, soweit ich weiß. Die 780 sagt mir zumindest nichts, wird aber wohl irgendein anderes Bauteil sein.

Ich habe es doch richtig verstanden, dass ich bei den ABFRAGEN Parameter die Checkbox bei "Automatisch einen Wert setzen" markieren muss, wenn ich diesen Wert in den Objekten immer aktuell haben möchte?
Und bei den SETZEN Parametern muss ich Garnichts machen also nichts anhaken?

Genau und bei "Automatisch einen Wert setzen" dann auch noch den gewünschten Zeitintervall einstellen, in dem die Daten abgefragt werden sollen.

2024-11-30 13:17:27.216	warn	Parser writing data for message ID 680 parser ID fa0930 failed: ReferenceError: setStateAsync is not defined

Das kommt, wenn du die latest Version der Config nutzt, aber aktuelle stable Version vom Adapter. Die setStateAsync Funktion in den Parser-Skripten wird erst seit Adapterversion 2.1.x unterstützt. Mit der Adapterversion 2.1.1 aus dem latest Repo sollte das funktionieren. Die ist, bis auf einen kleinen Schönheitsfehler im Layout der Konfiguration, soweit stabil.

@ag Super, dann bin ich ja schon mal beruhigt, dass es doch nicht am Adapter liegt
Bzgl. der Warnung: Schau mal bei dem Parser, was da als Lesen-Skript drin steht. Auch wenn es hier nicht genutzt wird, darf das Feld nicht leer sein, sondern sollte einfach einen Kommentar (im einfachsten Fall nur //) enthalten.

@ag Danke für deine Tests. Leider kann ich das bei mir absolut nicht nachstellen

@ag sagte in Rotex HPSU / Daikin Altherma Wärmepumpe über ioBroker.canbus:

Leider nicht. Adapterversion 2.1.1

Hmm seltsam... habe eben bei mir noch mal die 2.1.1 zum Testen neu installiert. Da klappt es wie gedacht und die beiden Nachrichten werden beim auslösen von 680.fa0930 gesendet:

  vcan0  680   [7]  31 00 FA C2 EE 00 00
  vcan0  680   [7]  31 00 FA 09 30 00 00

(vcan0, da ich zum Testen ein virtuelles CAN-Interface nutze)

@ag Sollte mit v2.1.1 jetzt behoben sein.

Nochmals eine neue Adapterversion 2.1.0.
Neu sind dieses mal nur zusätzliche verfügbare Funktionen in den Skripten der Custom Parser.

@ag Ich habe die latest-Config für die Wärmepumpe jetzt für fa0930 (Energie gesamt) angepasst, sodass hier nun im Hintergrund die beiden IDs abgefragt werden sollten und der Überlauf einberechnet wird.
Mit der Adapterversion zusammen kannst du die Config neu von GitHub laden, oder die beiden Scripte in den Parsern wie folgt anpassen:

180.fa0930 Lesen (für die Antworten)

// fac2ee lesen und in sharedData für später speichern
if ((buffer[0] & 0x0F) === 0x02 && buffer[2] === 0xFA && buffer[3] === 0xC2 && buffer[4] === 0xEE) {
  sharedData.fac2ee = buffer.readInt16BE(5);
}
// fa0930 lesen
if ((buffer[0] & 0x0F) === 0x02 && buffer[2] === 0xFA && buffer[3] === 0x09 && buffer[4] === 0x30) {
  value = buffer.readInt16BE(5);
  // Überläufe aus fac2ee einrechnen, sofern vorhanden
  if (sharedData.fac2ee) {
    value += 32768 * sharedData.fac2ee;
  }
}

680.fa0930 Schreiben (für die Abfrage)

// erst fac2ee durch direktes schreiben in den json-State abfragen
buffer = Buffer.from([0x31, 0x00, 0xFA, 0xC2, 0xEE, 0x00, 0x00]);
await setStateAsync('680.json', JSON.stringify([ ...buffer ]), false);
// dann 1 Sekunde später fa0930 normal abfragen
await wait(1000);
buffer = Buffer.from([0x31, 0x00, 0xFA, 0x09, 0x30, 0x00, 0x00]);
// Info: der entsprechende Lesen-Parser 180.fa0930 behandelt das Lesen von beiden IDs

Sofern das so klappt wie gedacht, werde ich nach dem gleichen Muster auch noch die Energien für Heizung und Warmwasser mit einbauen.

Ab sofort steht vom canbus-Adapter die Version 2.0.0 bereit.

Neben vielen Aktualisierungen wurde auch Art, wie die Skripte der Custom-Parser interpretiert werden geändert.
Da die gesamte Kommunikation mit der Wärmepumpe hier über solche Parser Skripte läuft, wäre es super, wenn einer von euch das mit der neuen Adapterversion testen könnte.

Eigentlich sollte alles wie vorher laufen. Fehler sind aber dennoch nicht auszuschließen.

Die aktuelle latest Version der Rotex HPSU Compact / Daikin Altherma Config benötigt ab sofort mindestens Adapterversion 2.0.0.
Grund ist, dass für die Funktion Heizstäbe setzen nun eine Prüfung eingebaut ist, die verhindern soll, dass diese Funktion während des Modus Heizen aktiviert wird. (Danke an @KalaNagHTD fürs Melden des Problems)

@ag sagte in Rotex HPSU / Daikin Altherma Wärmepumpe über ioBroker.canbus:

   can0  10A   [7]  31 00 FA 09 30 00 00
   can0  180   [7]  22 0A FA 09 30 06 08
   can0  10A   [7]  31 00 FA C2 EE 00 00
   can0  180   [7]  22 0A FA C2 EE 00 02

Der angezeigte Wert passt zur 06 08 bei FA0930 + 2 Überläufe der Variable.
Ich würde jetzt vermuten, dass die Überläufe in FAC2EE mit 00 02 gezählt sind.
Kann das irgendwer bestätigen, der einen "Energie WP gesamt" Wert zwischen 32768 und 65534 kWh hat?

 can0  10A   [7]  31 00 FA 06 A7 00 00
 can0  180   [7]  22 0A FA 06 A7 56 82
 can0  10A   [7]  31 00 FA C2 ED 00 00
 can0  180   [7]  22 0A FA C2 ED 00 01

Das müsste dann "Energie WP Heizung" sein mit 56 82 = 22146 + 1 Überlauf (32768) = 54914 kWh

 can0  10A   [7]  31 00 FA 09 2C 00 00
 can0  180   [7]  22 0A FA 09 2C 2F CF
 can0  10A   [7]  31 00 FA C2 EF 00 00
 can0  180   [7]  22 0A FA C2 EF 00 00

Und das dann "Energie WP Kühlung" mit 2F CF = 12239 + 0 Überläufe = 12239 kWh

Ich baue das die nächsten Tage, sobald ich Zeit dafür finde, mal in die Config ein.

@ag Hmm... also in der Nachricht kommen ja nur 16 Bit an Daten mit, also kann der gelesene Wert nie größer werden.
Eventuell gibt es dazu noch eine zweite Nachricht mit anderer ID anstelle von fa0930, womit dann zusammen mit diesem der richtige Wert ermittelt werden kann.

Kann man den Wert über die originale Steuerung irgendwie aktiv abfragen?
Wenn ja, dann das mal bitte machen und dabei einen candump mitlaufen lassen. Den Dump und den Wert, der in der Steuerung angezeigt wird dann bitte mal posten