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.

@mcm1957 sagte in Tipp zum ODL Adapter:

@crycode Release 5 build ist gescheiter falls du es noch nicht gesehen hast. engines >= 20 ist mit node.js 18 Tests nicht so ganz kompatibel :-). Ergo bitte noch TestMatrix anpassen. Node 24 kann da dafür schon testweise rein.

Huch, ja hab ich auch gerade gesehen. Fix ist unterwegs

Edit: Jetzt ist der Release aber durch.

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.

Aktuelle Test Version	1.2.x
Veröffentlichungsdatum	22.06.2021
Github Link	https://github.com/crycode-de/ioBroker.canbus

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

Aktuelle Test Version	2.0.4
Veröffentlichungsdatum	20.08.2023
Github Link	https://github.com/crycode-de/ioBroker.ds18b20

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.

In der neuesten Adapter-Version 5.0.0 ist nun ein Hinweis dazu direkt in der Konfigurationsseite enthalten.

Dazu habe ich auch die Docs um einen Abschnitt dafür ergänzt.

@mcm1957 Danke für die Info über den Issue!

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?

Hi, das gleiche "Problem" hatte ich mit dem Max! Cube Adapter auch.

Dazu habe ich dann folgendes Skript erstellt, welches den Moduswechsel zusammen mit der Verstellung der Soll-Temperatur erkennt und das Thermostat zurück auf Auto stellt:

/**
 * ioBroker Skript zum automatischen Zurücksetzen des Modus von MAX! Thermostaten
 * auf Auto, wenn die Solltemperatur im Auto-Modus geändert wurde.
 *
 * Dies ist erforderlich, da die Thermostate durch den Max! Cube Adapter bei einer
 * manuellen Änderung der Solltemperatur immer in den manuellen Modus versetzt werden.
 * Dieses Script erkennt diese Änderung und setzt den Modus zurück auf Auto.
 *
 * Copyright (c) 2019-2021 Peter Müller  (https://crycode.de)
 */

/**
 * Liste an Thermostaten, die ignoriert werden sollen.
 * Dies können z.B. Wandthermostate sein, da diese zusammen mit dem zugehörigen 
 * Heizkörperthermostat arbeiten.
 */
const thermostatIgnore = [
  'thermostat_18abcd'
];

// Auflistung aller Thermostate holen
const devices = $('maxcube.0.devices.thermostat_*.mode');

// Alle Thermostate durchgehen
devices.each((id) => {
  id = id.replace(/\.mode$/, '');

  // Prüfen ob das aktuelle Thermostat ignoriert werden soll
  const rfId = id.split('.')[3];
  if (thermostatIgnore.indexOf(rfId) !== -1) return;

  log('setup mode switch back for ' + id);

  // Handler für einen Moduswechsel anlegen
  on({ id: id + '.mode', change: 'ne'}, (obj) => {
    // AUTO(0) -> MANUAL(1) ?
    if (obj.newState.val === 1 && obj.oldState.val === 0) {
      // Letzte Sollwertänderung laden und Zeitpunkt prüfen
      getState(id + '.setpoint', (err, state) => {
        // Wechsel des Modus innerhalb von 10 Sekunden nach dem Wechsel des Sollwerts?
        if (state.ts > obj.newState.ts - 10000) {
          // Modus zurück auf Auto setzen
          log('switching ' + id + ' back to auto mode');
          setState(id + '.mode', 0);
        }
      });
    }
  });
});

Das Skript kann direkt so ohne Änderungen übernommen werden. Bei Bedarf kann man über das thermostatIgnore Array einzelne Thermostate ausschließen.

Solange das Skript aktiv ist, werden damit dann die Thermostate wieder zurück auf Auto gestellt, sodass bei der nächsten planmäßigen Temperaturänderung wieder auf die eingestellt Temperatur gewechselt wird.

@michaelk
Hmm... den Rebuild hätte ioBroker eigentlich von selbst anstoßen müssen in dem Fall.
Aber schön, dass es nun läuft.

@michaelk Aktuell sollten Node.js 20.x und 22.x unterstützt sein.
24.x ist aktuell leider (noch) nicht unterstützt, da die zugrundeliegende Lib noch kein 24 unterstützt. Wann dies soweit sein wird, kann ich leider nicht sagen oder beeinflussen.

@elektroniker86 Die Version 2.1.1 sollte über das latest Repo verfügbar sein. Alternativ kannst auch von NPM installieren. Direkt von GitHub bitte aktuell nicht installieren, da ich hier grad an der nächsten Version arbeite.

@mcm1957 sagte in Tipp zum ODL Adapter:

@crycode Release 5 build ist gescheiter falls du es noch nicht gesehen hast. engines >= 20 ist mit node.js 18 Tests nicht so ganz kompatibel :-). Ergo bitte noch TestMatrix anpassen. Node 24 kann da dafür schon testweise rein.

Huch, ja hab ich auch gerade gesehen. Fix ist unterwegs

Edit: Jetzt ist der Release aber durch.

In der neuesten Adapter-Version 5.0.0 ist nun ein Hinweis dazu direkt in der Konfigurationsseite enthalten.

Dazu habe ich auch die Docs um einen Abschnitt dafür ergänzt.

@mcm1957 Danke für die Info über den Issue!

@elektroniker86 Die Warnungen kommen daher, dass die latest Konfiguration auch die latest Version vom Adapter benötigt. Da bin ich leider noch nicht zu gekommen, diese in stable zu überführen. Sollte aber problemlos laufen.

680.fa0144 und 680.fa0144-set sind eigentlich in der Konfiguration ab Konfiguratoins-Version 1.5.0 drin. Siehe hier.

PS.: Ich habe die Infos zum SystemD Service jetzt in meiner Anleitung ergänzt.

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

systemd-networkd is not running, output will be incomplete.

Ok, dann läuft auf dem System der systemd-networkd offenbar (auch) nicht.

Dann kannst du noch einen SystemD Oneshot Service anlegen, der beim Systemstart einmalig gestartet wird.
/etc/systemd/system/setup-can0.service

[Unit]
Description=Setup can0
After=network.target

[Service]
Type=oneshot
ExecStart=/sbin/ip link set can0 up type can bitrate 20000
RemainAfterExit=true

[Install]
WantedBy=multi-user.target

Und dann zum Aktivieren:

sudo systemctl daemon-reload
sudo systemctl enable setup-can0.service

Die vorhin angelegte Datei /etc/systemd/network/80-can0.network solltest du dann wieder löschen.

Die vielen "returned undefined" Meldungen sind in dem Fall normal und besagen nur, dass die jeweiligen Parser nicht zu der empfangenen Nachricht passten.

@elektroniker86 Hi, ja bei neueren Versionen wird die Netzwerkkonfiguration anders gehandhabt (ich meine mit Netplan) und daher gibt es die interfaces Datei nicht mehr.

Dafür sollte es aber funktionieren, die Sache dem SystemD zu überlassen mit folgender Konfiguration:
/etc/systemd/network/80-can0.network

[Match]
Name=can0

[CAN]
BitRate=20K

Zum Anwenden des Ganzen entweder neu starten oder sudo networkctl reload.

@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.