Home Assistant Anbindung

[derAngler]

Besteht Hoffnung das Tinkerforge an einer Home Assistant Anbindung arbeitet?
Ich finde das würde super zusammen passen, wenn man in Home Assistant auf die Sensoren und Aktoren von Tinkerforge zugreifen könnte, das wäre WoW!
Und so schwer kann es doch eigentlich nicht sein die MQTT Anbindung etwas umzubauen, so das sie mit HA funktioniert?

[rtrbt]

Moin,

On 11/20/2020 at 8:48 PM, derAngler said:

Besteht Hoffnung das Tinkerforge an einer Home Assistant Anbindung arbeitet?

Im Moment eher nicht. Du kannst aber die MQTT-Bindings benutzen, mit einem init_file Callbacks für die Werte aktivieren die dich interessieren und dann mit der MQTT-Sensor-Integration die Werte in Home Assistant bekommen.

[derAngler]

ja, das ich mir das quasi selbst programmieren kann ist mir klar.
Hatte die Hoffnung mir die Arbeit zu sparen :)

[derAngler]

Zitat

... Du kannst aber die MQTT-Bindings benutzen, mit einem init_file Callbacks für die Werte aktivieren die dich interessieren und dann mit der MQTT-Sensor-Integration die Werte in Home Assistant bekommen.

Da ich wohl doch der einzige bin der Interesse an einer Umsetzung von Tinkerforge nach Home Assistant interessiert ist muss ich mich wohl hinsetzen und das irgendwie programmieren.
Leider habe ich so gar keine Ahnung wie ich das am besten anfange.
Was ist mit "kannst aber die MQTT-Bindings benutzen, mit einem init_file Callbacks für die Werte aktivieren" gemeint, vor allem wie "init_file Callback" umsetzen kann.
Hat irgendwer eine Tip oder einen kleinen Stück Beispiel-Code für mich?
Am liebsten in python ;)

[rtrbt]

Ich meinte damit folgendes: Du kannst die MQTT-Bindings von uns (hier: https://www.tinkerforge.com/de/doc/Software/API_Bindings_MQTT.html) benutzen und die Werte mit der oben verlinkten MQTT-Sensor-Integration von Home Assistant auslesen. Wenn du da etwas runterscrollst kommt eine Erklärung, wie du mit JSON-Daten (das Format benutzen wir für die MQTT-Bindings) umgehen kannst.

Du musst dann noch die Callbacks der Bricks/Bricklets aktivieren, die du benutzen willst. Dafür kannst du ein init_file schreiben, das ist eine Konfigurationsdatei für die MQTT-Bindings, die initial ausgeführt wird.

Am besten experimentierst du etwas mit den MQTT-Bindings, Mosquitto mit den mosquitto_pub- und _sub-Befehlen bieten sich da an.

 

Wenn du wirklich eine native Home Assistent-Anbindung (also ein Binding) schreiben willst: das ist vom Aufwand her vergleichbar mit den openHAB-Bindings in die ich schon ungefähr 9 Monate Arbeit versenkt habe, da würde ich dir eher von abraten.

[ngblume]

Hallo zusammen,

ich habe mal das Beispiel mit einem Outdoor Weather Bricklet durchgespielt und es hat mich etwas Zeit gekostet, das Zusammenspiel von tinkerforge-mqtt und den Dateien zu verstehen. Daher mal meine Dateien als ein "konkretes" Beispiel im Anwendungsfall:

1. Erfassung der Daten über Tinkerforge
2. Publish als MQTT
3. Anbindung an HomeAssistant als MQTT-Sensor (hier habe ich Fragen...).

In meinem Aufbau habe ich ein Outdoor-Weather Bricklet (UID: "Er2") mit einer Station und mehreren Sensoren (um die 6...). Der Tinkerforge-MQTT Daemon läuft auf einem Raspberry Pi, an dem per USB das Bricklet mit einem Master Brick angeschlossen ist.

daemon-cmd-args

=====

--ipcon-host 127.0.0.1
--ipcon-port 4223
--broker-host homeassistant.local
--broker-username user
--broker-password password
--debug
--symbolic-response
--show-payload
--init-file daemon-init-msgs

=====

daemon-init-msgs

{
    "tinkerforge/request/outdoor_weather_bricklet/Er2/set_station_callback_configuration": {"enable_callback": true},
    "tinkerforge/request/outdoor_weather_bricklet/Er2/set_sensor_callback_configuration": {"enable_callback": true},
    "tinkerforge/register/outdoor_weather_bricklet/Er2/station_data": {"register": true},
    "tinkerforge/register/outdoor_weather_bricklet/Er2/sensor_data": {"register": true}
}

=====

Starten des Daemon mit "tinkerforge_mqtt --cmdline-file daemon-cmd-args" führt dazu, dass die Daten entsprechend in MQTT publiziert werden:

Topic: "tinkerforge/callback/outdoor_weather_bricklet/Er2/sensor_data"

Data: {"temperature": 227, "identifier": 214, "humidity": 63}

=====

Frage(n):

Die üblichen Dokumentationen für MQTT-Sensor in HA sehen vor, dass es ein Topic pro Sensor gibt (bspw. "homeassistant/sensor/plant_sensor_1/temperature/config" für MQTT-Discovery). Nun ist der Ansatz bei Tinkerforge im Falle des Outdoor-Bricklets umgekehrt. Unter "tinkerforge/callback/outdoor_weather_bricklet/Er2/sensor_data" werden die Daten verschiedener Sensoren veröffentlicht, wobei zur Unterschiedung der "identifier" enthalten ist.

1. Ist hier überhaupt eine direkte Nutzung in HomeAssist möglich, da ja hier basierend auf dem "identifier" eine Aufteilung auf verschiedene Entities erfolgen müsste?
2. Und wäre es nicht für Tinkerforge sinnvoller, unterhalb des Bricklets und der Aufteilung nach Station oder Sensor noch nach den Identifiern aufzuteilen? Bspw. "tinkerforge/callback/outdoor_weather_bricklet/Er2/sensor_data/214/" für den Sensor mit der Identifier "214" aus obigen Beispieldaten ?
3. Wie kann ich den Daemon mit diesem CMD-File als Service starten, sodass ich keine blockierte Konsole habe?

Danke !!
Und danke für die super Hardware/Software und den Support !

Grüße
Niels Göran

bearbeitet August 23, 2021 at 06:31 von ngblume

[rtrbt]

Moin Niels,

12 hours ago, ngblume said:

Ist hier überhaupt eine direkte Nutzung in HomeAssist möglich, da ja hier basierend auf dem "identifier" eine Aufteilung auf verschiedene Entities erfolgen müsste?

Mit etwas Bastelei sollte das gehen. Habe spontan das hier gefunden:

https://community.home-assistant.io/t/multi-sensor-using-same-mqtt-topic/172552/3

Der Teil mit dem "data demultiplexer" sieht nützlich aus.

12 hours ago, ngblume said:

Und wäre es nicht für Tinkerforge sinnvoller, unterhalb des Bricklets und der Aufteilung nach Station oder Sensor noch nach den Identifiern aufzuteilen? Bspw. "tinkerforge/callback/outdoor_weather_bricklet/Er2/sensor_data/214/" für den Sensor mit der Identifier "214" aus obigen Beispieldaten ?

In diesem Fall wäre es sinnvoller, aber so funktionieren die Bindings nicht. Die Bindings mappen 1:1 auf die Python-API und in der sind die Sensor-IDs ein Rückgabewert. Das ist immer das Problem bei "generischen" MQTT-Bindings, wenn es ein reines HA-Binding wäre, sähe das anders aus.

12 hours ago, ngblume said:

Wie kann ich den Daemon mit diesem CMD-File als Service starten, sodass ich keine blockierte Konsole habe?

Hast du die Bindings auf dem Pi als Debian-Paket installiert? Falls ja kannst du deine cmdline-Datei nach /etc/tinkerforge_mqtt.cmdline packen bzw. mit der Datei zusammenlegen.

Falls du die Bindings von Hand heruntergeladen hast kannst du die .service-Datei aus dem Zip bearbeiten und  --cmdline-file daemon-cmd-args einfügen.

[ngblume]

Hallo,

7 minutes ago, rtrbt said:

https://community.home-assistant.io/t/multi-sensor-using-same-mqtt-topic/172552/3

Der Teil mit dem "data demultiplexer" sieht nützlich aus.

danke für den Tip mit dem Data Multiplexer... Den Link habe ich schon mal offen gehabt, aber irgendwie unter "passt nicht"  wieder geschlossen...
Schaue nochmal in Ruhe in die Details und dann sollte es hoffentlich machbar sein...

5 minutes ago, rtrbt said:

In diesem Fall wäre es sinnvoller, aber so funktionieren die Bindings nicht. Die Bindings mappen 1:1 auf die Python-API und in der sind die Sensor-IDs ein Rückgabewert. Das ist immer das Problem bei "generischen" MQTT-Bindings, wenn es ein reines HA-Binding wäre, sähe das anders aus.

Nachvollziehbar, aber ja beim Übergang vom Empfang mittels der Python-API als Callback zum Publishen auf den MQTT-Topics abhängig von einem Config-Parameter "Split by Identifier" sicherlich relativ einfach und sinnvoll machbar... Und wäre auch der allgemeinere Ansatz im Vergleich zu MQTT-Sensoren...

7 minutes ago, rtrbt said:

Hast du die Bindings auf dem Pi als Debian-Paket installiert? Falls ja kannst du deine cmdline-Datei nach /etc/tinkerforge_mqtt.cmdline packen bzw. mit der Datei zusammenlegen.

Bindings als Debian-Paket installiert > Ansatz probiere ich auch und melde mich ggf. bei Problemen nochmal...

Danke !

Grüße
Niels Göran

[ngblume]

Hallo,

kurz als Log, wie ich es am Ende gelöst habe:

1. Inhalt von daemon-cmd-args in /etc/tinkerforge_mqtt.cmdline ganz an den Anfang setzen und den Pfad zur daemon-init-msgs entsprechend absolut gestalten und anpassen (ich habe die Datei einfach "daneben" in /etc abgelegt.
2. Den systemd Service "tinkerforge_mqtt" mittels "systemctl enable tinkerforge_mqtt" aktivieren (wird damit immer beim Booten gestartet mit der Datei "/etc/tinkerforge_mqtt.cmdline" als CMD-Line-Parameter; und von dort werden dann die daemon-init-msgs ausgeführt)
3. in HomeAssistant sind die folgenden Dinge notwendig:
   1. Demultiplexing mittels einer Automation (https://www.home-assistant.io/docs/automation/)
      Hier dient die MQTT-Nachricht von den Tinkerforge-MQTT-Bindings als Trigger genutzt.
      Dieser Trigger löst ein Re-Publishing der MQTT-Nachricht in jeweils ein Topic pro Sensor / Station aus (die komplette Nachricht wird nochmal mittels Publish gesendet (inkl. des ungenutzten Identifiers)
   2. Pro Sensor und Sensor-Wert muss ein einzelner MQTT-Sensor angelegt werden (https://www.home-assistant.io/integrations/sensor.mqtt/)
      Bei dem Battery-Zustand muss ein MQTT-Binary-Sensor in HomeAssistant verwendet werden (https://www.home-assistant.io/integrations/binary_sensor.mqtt/).

Insgesamt sind also 2 Automations (Demultiplexing für Sensor; Demultiplexing für Station) und beliebig viele MQTT-Sensoren (je einer pro Sensor / Station und Messwert) notwendig.

Hier die 2 Automationen:

- id: "1641339259491"
  alias: TF-MQTT-Demultiplexing-SENSORS
  description: "Demultiplex SENSOR data as received from Tinkerforge outdoor weather bricklet and MQTT-Proxy by TF"
  trigger:
    - platform: mqtt
      topic: tinkerforge/callback/outdoor_weather_bricklet/Er2/sensor_data
      id: tf_weather_received_sensor_data
  condition: []
  action:
    - service: mqtt.publish
      data:
        retain: true
        topic_template: tf/weather/sensor_{{ trigger.payload_json.identifier }}
        payload: "{{ trigger.payload_json | tojson }}"
  mode: queued
  max: 10
- id: "1641342104861"
  alias: TF-MQTT-Demultiplexing-STATIONS
  description: "Demultiplex STATION data as received from Tinkerforge outdoor weather bricklet and MQTT-Proxy by TF"
  trigger:
    - platform: mqtt
      topic: tinkerforge/callback/outdoor_weather_bricklet/Er2/station_data
  condition: []
  action:
    - service: mqtt.publish
      data:
        retain: true
        topic_template: tf/weather/station_{{ trigger.payload_json.identifier }}
        payload: "{{ trigger.payload_json | tojson}}"
  mode: queued
  max: 10

Und hier alle Sensoren (außer Batterie der Station, da es sich um einen Binary-Sensor handelt):

# TF-sensor-data (temperature, humidity)
# =========================================================================
# SENSOR - ID #13 ("??")
- platform: mqtt
  name: "TF-Weather-Sensor-13-Temp"
  unique_id: "tf-weather-sensor-13-temp"
  state_topic: "tf/weather/sensor_13"
  value_template: "{{ value_json.temperature / 10 }}"
  unit_of_measurement: "°C"
  device_class: "temperature"

- platform: mqtt
  name: "TF-Weather-Sensor-13-Humidity"
  unique_id: "tf-weather-sensor-13-humidity"
  state_topic: "tf/weather/sensor_13"
  value_template: "{{ value_json.humidity }}"
  unit_of_measurement: "%"
  device_class: "humidity"
# =========================================================================
# SENSOR - ID #014 ("ANBAU")
- platform: mqtt
  name: "TF-Weather-Sensor-14-Temp"
  unique_id: "tf-weather-sensor-14-temp"
  state_topic: "tf/weather/sensor_14"
  value_template: "{{ value_json.temperature / 10 }}"
  unit_of_measurement: "°C"
  device_class: "temperature"

- platform: mqtt
  name: "TF-Weather-Sensor-14-Humidity"
  unique_id: "tf-weather-sensor-14-humidity"
  state_topic: "tf/weather/sensor_14"
  value_template: "{{ value_json.humidity }}"
  unit_of_measurement: "%"
  device_class: "humidity"
# =========================================================================
# SENSOR - ID #108 ("??")
- platform: mqtt
  name: "TF-Weather-Sensor-108-Temp"
  unique_id: "tf-weather-sensor-108-temp"
  state_topic: "tf/weather/sensor_108"
  value_template: "{{ value_json.temperature / 10 }}"
  unit_of_measurement: "°C"
  device_class: "temperature"

- platform: mqtt
  name: "TF-Weather-Sensor-108-Humidity"
  unique_id: "tf-weather-sensor-108-humidity"
  state_topic: "tf/weather/sensor_108"
  value_template: "{{ value_json.humidity }}"
  unit_of_measurement: "%"
  device_class: "humidity"
# =========================================================================
# SENSOR - ID #132 ("??")
- platform: mqtt
  name: "TF-Weather-Sensor-132-Temp"
  unique_id: "tf-weather-sensor-132-temp"
  state_topic: "tf/weather/sensor_132"
  value_template: "{{ value_json.temperature / 10 }}"
  unit_of_measurement: "°C"
  device_class: "temperature"

- platform: mqtt
  name: "TF-Weather-Sensor-132-Humidity"
  unique_id: "tf-weather-sensor-132-humidity"
  state_topic: "tf/weather/sensor_132"
  value_template: "{{ value_json.humidity }}"
  unit_of_measurement: "%"
  device_class: "humidity"
# =========================================================================
# SENSOR - ID #214 ("??")
- platform: mqtt
  name: "TF-Weather-Sensor-214-Temp"
  unique_id: "tf-weather-sensor-214-temp"
  state_topic: "tf/weather/sensor_214"
  value_template: "{{ value_json.temperature / 10 }}"
  unit_of_measurement: "°C"
  device_class: "temperature"

- platform: mqtt
  name: "TF-Weather-Sensor-214-Humidity"
  unique_id: "tf-weather-sensor-214-humidity"
  state_topic: "tf/weather/sensor_214"
  value_template: "{{ value_json.humidity }}"
  unit_of_measurement: "%"
  device_class: "humidity"
# =========================================================================
# STATION - ID #147 ("??")
- platform: mqtt
  name: "TF-Weather-Station-147-Temp"
  unique_id: "tf-weather-station-147-temp"
  state_topic: "tf/weather/station_147"
  value_template: "{{ value_json.temperature / 10 }}"
  unit_of_measurement: "°C"
  device_class: "temperature"

- platform: mqtt
  name: "TF-Weather-Station-147-Humidity"
  unique_id: "tf-weather-station-147-humidity"
  state_topic: "tf/weather/station_147"
  value_template: "{{ value_json.humidity }}"
  unit_of_measurement: "%"
  device_class: "humidity"

- platform: mqtt
  name: "TF-Weather-Station-147-GustSpeed"
  unique_id: "tf-weather-station-147-gustspeed"
  state_topic: "tf/weather/station_147"
  value_template: "{{ value_json.gust_speed / 10 }}"
  unit_of_measurement: "m/s"

- platform: mqtt
  name: "TF-Weather-Station-147-WindSpeed"
  unique_id: "tf-weather-station-147-windspeed"
  state_topic: "tf/weather/station_147"
  value_template: "{{ value_json.wind_speed / 10 }}"
  unit_of_measurement: "m/s"

- platform: mqtt
  name: "TF-Weather-Station-147-Rain"
  unique_id: "tf-weather-station-147-rain"
  state_topic: "tf/weather/station_147"
  value_template: "{{ value_json.rain / 10 }}"
  unit_of_measurement: "mm"
# =========================================================================

Und hier der Batterie-Sensor:

# =========================================================================
# STATION - ID #147 ("??")
- platform: mqtt
  name: "TF-Weather-Station-147-Battery"
  unique_id: "tf-weather-station-147-battery"
  state_topic: "tf/weather/station_147"
  device_class: battery
  payload_on: "true"
  payload_off: "false"
  value_template: "{{ value_json.battery_low }}"
# =========================================================================

 

Ich hoffe, dass dies dem einen oder anderen bei der Anbindung hilft.

Grüße
Niels Göran

bearbeitet January 5, 2022 at 13:00 von ngblume

[teichsta]

schönen Dank für Deinen sehr ausführlichen Beitrag hier @ngblume … ergänzend nur noch die Frage: hast Du den Brick-Daemon auf dem gleichen RPi laufen wir HA? Welche Installationsmethode hast dafür verwendet?

[ngblume]

5 hours ago, teichsta said:

schönen Dank für Deinen sehr ausführlichen Beitrag hier @ngblume … ergänzend nur noch die Frage: hast Du den Brick-Daemon auf dem gleichen RPi laufen wir HA? Welche Installationsmethode hast dafür verwendet?

Hej hej,

nein, die laufen, historisch bedingt, auf zwei RPis (RPi3 für Tinkerforge; RPi4 mit Kpühlung für HA).

Home Assistant habe ich wie folgt installiert: "Home Assistant Operating System" gemäß folgender Anleitung:
https://www.home-assistant.io/installation/raspberrypi

Grüße
Niels Göran

[teichsta]

danke für die schnelle Antwort @ngblume … würde man das denn auch auf einem zum Laufen bringen? Ich starte in diesem Projekt gerade erst mit HA und bin noch nicht ganz durchgestiegen was wie geht …

[teichsta]

noch eine kurze Rückfrage, wo genau konfigurierst Du die Sensoren? Es sah für mich danach aus, als würde hier MQTT Sensors als Integration eingebunden werden, aber das scheint so nicht zu gehen, weil sie mir dort nicht angeboten werden. Any hint?

[ngblume]

On 7/6/2022 at 2:36 PM, teichsta said:

noch eine kurze Rückfrage, wo genau konfigurierst Du die Sensoren? Es sah für mich danach aus, als würde hier MQTT Sensors als Integration eingebunden werden, aber das scheint so nicht zu gehen, weil sie mir dort nicht angeboten werden. Any hint?

Hallo,

ich bin ein Freund von funktionaler Trennung:
1 RPi für HA und 1 RPi für TF... Aber du kannst auch beides auf einem laufen lassen, aber...

Die HA Installation mit "Home Assistant Operating System" ist tief im System verankert > daher auch HA "Operating System"..
Ich würde es trennen...

Du hast es richtig gesehen, dass hier MQTT verwendet wird..
Hierbei senden die TF-Bindings für MQTT auf einigen Topics an den in HA eingebauten MQTT-Server...
In HA sind ein paar "Verarbeitungen" eingebaut, die MQTT empfangen und dann "zerteilen" nach der ID des Sensors und wieder auf eindeutigen Topics (1 Topic pro Sensor) senden. Dies wird in HA unter dem Stichwort "Automationen" geführt.

Konkret wie in folgendem Post beschrieben:

1. die TF MQTT Bindings senden auf die folgenden Topics. Je eines der Topics ist als Trigger für eine Automation hinterlegt. 
   1. "tinkerforge/callback/outdoor_weather_bricklet/Er2/sensor_data"
   2. "tinkerforge/callback/outdoor_weather_bricklet/Er2/station_data"
2. diese Automationen broadcasten die verarbeiteten Nachrichten auf Topics im Stile von:
   "topic_template: tf/weather/station_{{ trigger.payload_json.identifier }}" > also bspw. "tf/weather/station_145", wenn die Station die ID "145" hat

auf all diese Topics ist je ein "virtueller" Sensor registriert mit meist 2 Values (station hat mehr), sprich er hat dieses Topic als Trigger:

# SENSOR - ID #214 ("??")
- platform: mqtt
  name: "TF-Weather-Sensor-214-Temp"
  unique_id: "tf-weather-sensor-214-temp"
  state_topic: "tf/weather/sensor_214"
  value_template: "{{ value_json.temperature / 10 }}"
  unit_of_measurement: "°C"
  device_class: "temperature"

- platform: mqtt
  name: "TF-Weather-Sensor-214-Humidity"
  unique_id: "tf-weather-sensor-214-humidity"
  state_topic: "tf/weather/sensor_214"
  value_template: "{{ value_json.humidity }}"
  unit_of_measurement: "%"
  device_class: "humidity"

MQTT ist somit keine klassische Extension, sondern eine "Plattform"....
Keine Ahnung, ob es da etwas schöneres zur Konfiguration gibt...

Hoffe, dass hilft etwas..

Grüße
Niels Göran

[teichsta]

Update: ich habe hier nun eine funktionierende Installation mit dem oben beschriebenen Setup (2 RPis, Anbindung über MQTT Binding) laufen … so weit, so gut.

Da wir im Projekt allerdings allerdings mehrere Installationen (es geht um eine "Maschine" mit lokaler Visualisierung, deren Sensorik wir mit TF realisieren) haben, ist die Einrichtung/Konfiguration leider mit MQTT etwas "nervig", da die UIDs ja im Topicnamen auftauchen, damit auch in den Entities und damit auch in den Automationen. Insofern ist die Konfiguration leider nicht so richtig von der eigentlichen Hardware entkoppelt … jedenfalls habe ich das noch nicht hinbekommen.

Darüber hinaus habe ich vor die Temperatur(en) mit OneWire zu messen, was unglücklicherweise ein recht "kompliziertes" Protokoll ist und sich daher mit der HomeAssistant-Template-Sprache nur recht umständlich implementieren läßt. Insofern wäre eine native Integration schon irgendwie deutlich netter ... aber gut :-)

[Dosepower]

Moin ich habe homeassistant auf meinem NAS Laufen musst nur bei beim http request deine ip anpassen.

bekommst ein schönes payload wo du deine daten rausziehen kannst.

 

[{"id":"3072e780023c9660","type":"inject","z":"d7a5456d.669e78","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"20","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":330,"y":880,"wires":[["69de9a27d2fc4d31"]]},{"id":"69de9a27d2fc4d31","type":"http request","z":"d7a5456d.669e78","name":"","method":"GET","ret":"txt","paytoqs":"ignore","url":"http://192.168.178.24/evse/state","tls":"","persist":false,"proxy":"","insecureHTTPParser":false,"authType":"","senderr":false,"headers":[],"x":530,"y":880,"wires":[["752dc485127bb318"]]},{"id":"752dc485127bb318","type":"json","z":"d7a5456d.669e78","name":"","property":"payload","action":"","pretty":false,"x":710,"y":880,"wires":[["6b6c6e9bcc3e2f68"]]},{"id":"6b6c6e9bcc3e2f68","type":"debug","z":"d7a5456d.669e78","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":850,"y":880,"wires":[]}]

 

[ngblume]

On 8/9/2022 at 4:19 PM, teichsta said:

Update: ich habe hier nun eine funktionierende Installation mit dem oben beschriebenen Setup (2 RPis, Anbindung über MQTT Binding) laufen … so weit, so gut.

Da wir im Projekt allerdings allerdings mehrere Installationen (es geht um eine "Maschine" mit lokaler Visualisierung, deren Sensorik wir mit TF realisieren) haben, ist die Einrichtung/Konfiguration leider mit MQTT etwas "nervig", da die UIDs ja im Topicnamen auftauchen, damit auch in den Entities und damit auch in den Automationen. Insofern ist die Konfiguration leider nicht so richtig von der eigentlichen Hardware entkoppelt … jedenfalls habe ich das noch nicht hinbekommen.

Darüber hinaus habe ich vor die Temperatur(en) mit OneWire zu messen, was unglücklicherweise ein recht "kompliziertes" Protokoll ist und sich daher mit der HomeAssistant-Template-Sprache nur recht umständlich implementieren läßt. Insofern wäre eine native Integration schon irgendwie deutlich netter ... aber gut :-)

Hej hej,

Idee: die UIDs als Variablen in HomeAssistant anlegen und in den Automationen referenzieren und somit müsstest du nur die Variable pro Instanz ändern..

OneWire: HIer würde ich die TF-MQTT-Bindings umgehen und einen Python-Prozess laufen lassen, der die Daten einliest und dann per MQTT published.
Die kannst du dann wieder in HA einbinden...

Grüße
Niels Göran

[CChris]

Hi,
Ich versuche gerade ein Script zu schreiben, welches dann in der Lage sein soll, TF Bricks und Bricklets "dynamisch" auszulesen und Werte über den paho-mqtt client an einen Broker zu senden.
Der Grund, warum ich diesen Weg gehe - und nicht direkt die MQTT Bindings von Tinkerforge nutzen möchte ist, dass ich eigentlich recht wenig Aufwand in die Konfiguration auf seiten HomeAssistant haben möchte.
Ich möchte sämtliche Werte (erst einmal nur Sensoren einlesen und weiter geben) so strukturieren, dass sie über die Auto-Detection der MQTT integration erkannt werden und daraus dann direkt Sensoren generiert werden können.

Dadurch spart man sich das händische Anpassen der Config, wenn es eine Änderung in der Hardware gegeben haben sollte.

Später sollen, sofern ich das hinbekomme, auch Topics empfangen werden können, damit man auch aus HomeAssistant heraus "steuern" kann.
Aktuell bin ich aber noch in einem sehr frühen Stadium... es wird also noch etwas Zeit brauchen, bis das ganze soweit sein wird...

[ngblume]

12 hours ago, CChris said:

Der Grund, warum ich diesen Weg gehe - und nicht direkt die MQTT Bindings von Tinkerforge nutzen möchte ist, dass ich eigentlich recht wenig Aufwand in die Konfiguration auf seiten HomeAssistant haben möchte.
Ich möchte sämtliche Werte (erst einmal nur Sensoren einlesen und weiter geben) so strukturieren, dass sie über die Auto-Detection der MQTT integration erkannt werden und daraus dann direkt Sensoren generiert werden können.

Dadurch spart man sich das händische Anpassen der Config, wenn es eine Änderung in der Hardware gegeben haben sollte.

Hej hej,

einen vergleichbaren Ansatz hatte ich auch mal im Kopf, bin aber an zwei wichtigen Punkten aus der Tinkerforge-Welt, und im Besonderen aus der Welt des "Outdoor Weather Bricklets" gescheitert.. vielleicht kann jemand von Tinkerforge an dieser Stelle etwas helfen / verifizieren, dass es da ein systematisches Problem gibt..

In Home Assistant ist es nur sinnvoll, wenn Sensoren ihren logischen Orten / Funktionen zugeordnet sind.
Also einfach Sensor-Werte erfassen ist zwar schön, aber eigentlich musst du wissen, dass es sich um die Temperatur im Wohnzimmer (Beispiel) handelt, damit dir die Daten etwas sagen..
Wenn der Sensor nun kaputt geht, getauscht wird oder ein weiterer dazu kommt, weißt du wieder nichts über die Bedeutung der Daten..
Solltest du tauschen müssen, musst du trotzdem Home Assistant klar machen, dass dieser neue Wert jetzt den logischen Wert "Temperatur-Wohnzimmer"darstellt, damit die Historie weitergeht und alle Automationen, etc. weiterhin funktionieren..
Um dieses Mapping kommt man nicht herum.. zumindest bei Tinkerforge-Systemen nach meinem Wissen..

Besonders "hässlich" ist das in meinen Augen bei den beiden Sensoren zum Outdoor Weather Bricklet:

1. https://www.tinkerforge.com/en/shop/temperature-humidity-sensor-th-6148.html
2. https://www.tinkerforge.com/de/shop/outdoor-weather-station-ws-6147.html

Denn diese ändern ihre ID schon mit einem Batterie-Wechsel!! > @Tinkerforge: oder??
Und damit bist du ohne ein Mapping auch mit Auto-Discovery nicht in der Lage, die Historie eines logischen Messwerts (Temperatur-Wohnzimmer) nach einem Batterie-Tausch fortzusetzen..

So, das waren meine Erfahrungen dazu..
Viel Erfolg bei deinem Projekt (trotzdem) !!

Grüße
Niels Göran

 

[CChris]

vor 56 Minuten schrieb ngblume:

Hej hej,

...

Wenn der Sensor nun kaputt geht, getauscht wird oder ein weiterer dazu kommt, weißt du wieder nichts über die Bedeutung der Daten..
Solltest du tauschen müssen, musst du trotzdem Home Assistant klar machen, dass dieser neue Wert jetzt den logischen Wert "Temperatur-Wohnzimmer"darstellt, damit die Historie weitergeht und alle Automationen, etc. weiterhin funktionieren..
Um dieses Mapping kommt man nicht herum.. zumindest bei Tinkerforge-Systemen nach meinem Wissen..

Besonders "hässlich" ist das in meinen Augen bei den beiden Sensoren zum Outdoor Weather Bricklet:

1. https://www.tinkerforge.com/en/shop/temperature-humidity-sensor-th-6148.html
2. https://www.tinkerforge.com/de/shop/outdoor-weather-station-ws-6147.html

Denn diese ändern ihre ID schon mit einem Batterie-Wechsel!! > @Tinkerforge: oder??
Und damit bist du ohne ein Mapping auch mit Auto-Discovery nicht in der Lage, die Historie eines logischen Messwerts (Temperatur-Wohnzimmer) nach einem Batterie-Tausch fortzusetzen..

So, das waren meine Erfahrungen dazu..
Viel Erfolg bei deinem Projekt (trotzdem) !!

Grüße
Niels Göran

 

Hi,

danke für die Info :)
OK, ich habe keine Outdoor-Wetterstation zum testen da.
Tatsächlich ist die Hardware, welche ich hier habe z.T. 10 Jahre alt und hatte bisher nur Staub angesammelt... daher die Idee, mit dieser jetzt vielleicht doch etwas 'sinnvolleres' anzustellen :)

Ja, um das "Mapping" kommt man nicht drum herum, aber das ist letztendlich bei Tinkerforge so, wie bei allen anderen Geräten auch - wenn ich z.B. ein Thermostat von Homematik austausche, muss ich dieses auch erst in der CCU anlernen - umbennen - dann wird es in HomeAssistant erkannt & dann kann ich es zuweisen.
ggf. muss ich es auch hier noch einmal umbenennen um nicht alle Automatisierungen abändern zu müssen.
Da sehe ich (zumindest im Moment) - eigentlich keinen großen Unterschied.

Ich habe mir jetzt aber tatsächlich mal die Dokumentation für das Outdoor-Weather Bricklet angeschaut...

Zitat

BrickletOutdoorWeather.get_station_identifiers()

Rückgabe:	identifiers – Typ: [int, ...], Länge: variabel, Wertebereich: [0 bis 255]

Gibt die Identifier (Zahl zwischen 0 und 255) von allen 'Stationen <https://www.tinkerforge.com/de/shop/accessories/sensors/outdoor-weather-station-ws-6147.html>`__ die seit dem Start des Bricklets entdeckt wurden.

Jede Station gibt sich selbst einen zufälligen Identifier beim ersten Start.

Seit Firmware-Version 2.0.2 wird eine Station von der Liste wieder entfernt wenn für 12 Stunden am Stück keine Daten empfangen werden.

... jetzt steht hier leider nicht, ob der Identifier auch bei einem Batteriewechsel erhalten bleibt oder nicht - wenn nicht, macht das ja eine programmbasierte Zuweisung egal für was deutlich schwerer...
Auf der anderen Seite... wie viele Outdoor-Wetterstationen hat man i.d.R. daran angeschlossen?
Maximal vielleicht die Temperatur/LF-Sensoren ... da könnten ggf. mehrere im Einsatz sein...🤔

[ngblume]

27 minutes ago, CChris said:

jetzt steht hier leider nicht, ob der Identifier auch bei einem Batteriewechsel erhalten bleibt oder nicht - wenn nicht, macht das ja eine programmbasierte Zuweisung egal für was deutlich schwerer...
Auf der anderen Seite... wie viele Outdoor-Wetterstationen hat man i.d.R. daran angeschlossen?
Maximal vielleicht die Temperatur/LF-Sensoren ... da könnten ggf. mehrere im Einsatz sein..

Hej hej,

Erfahrung: geht bei jedem Batterie-Wechsel weg; und genau, es sind die Indoor Sender, die mehr Ärger machen..

Evtl. habe ich dann deine Idee falsch verstanden, aber Auto-Discovery mit anschließendem (händischen) Mapping bringt für mich keinen Vorteil gegenüber direkt händisch mappen aus einem MQTT-Explorer...

Grüße
Niels Göran

 

[CChris]

Hi @ngblume:
ich habe mir die Sache mit der sich ändernden ID bei einem Batteriewechsel noch einmal durch den Kopf gehen lassen.
Es ist zwar wirklich eine ziemlich doofe Sache - und ich verstehe nicht, warum das so umgesetzt wurde, aber Programmiertechnisch könnte man das ggf. abfangen...

Das ist jetzt nur ein Theoretischer Ansatz - ich habe ihn selber noch nicht versucht...

1. aufbauen einer Verbindung zum "Outdoor-Weather-Bricklet"
2. ermitteln der erkannten IDs
3. Für jede erkannte ID wird programmtechnisch eine eigene ID generiert.
4. diese Infos werden in einer Liste o.ä. geschrieben - sodass man eine Zuordnung der Wetter-Stations-ID zu der eigens generierten ID hat.

Nun gibt es m.E. drei Möglichkeiten:
1 - eine neue ID kommt hinzu, alle zuvor erkannten IDs sind noch vorhanden:
-> es wird ein Eintrag in der Liste ergänzt.

2 - eine neue ID kommt hinzu, eine zuvor gespeichterte ist nicht mehr 'verbunden':
-> in diesem Fall kann man davon ausgehen, dass sich die ID eines bereits bestehenden Gerätes durch z.B. einen Batteriewechsel geändert hat.
Es wird daher ein Update auf den Listeneintrag der IDs gemacht ... die neue ID bekommt nun die eigene ID zugewiesen.

3 - eine ID wird nicht mehr gefunden, es kommt aber keine neue Hinzu:
-> man lässt den Eintrag in der Liste bestehen, falls doch noch Fall 2 Eintritt...

Wie gesagt, bisher nur Theoretisch... da ich selber keine Wetterstation im Einsatz habe - und selber aktuell nur ältere Bricklets meist aus der 1. Generation da habe...
Aber meine Frau möchte ggf. tatsächlich so ein Teil noch haben, also könnte ich mich irgendwann demnächst mal genauer damit Außeinander setzen :D

Allerdings frage ich mich gerade auch, ob das Weather-Bricklet NUR mit den hier verfügbaren Wetterstationen zurecht kommt, oder ggf. auch mit anderen Funk-Stationen, welche auf 433 MHz laufen?
Weißt du da zufällig etwas?

[Superp]

Hi guys,

Sorry for entering the discussion in the wrong language.

I have used mapping for sensor id's since about six months, and it makes life much easier. Your discussion prompted me to publish the (Ruby) code. Maybe this gives you an idea of how (not) to do this.

Here is an example of the result:

# retrieve data for all sensors
my_weather_bricklet.sensors
=> {163 => [19.0, 54, 25], 202 => [11.1, 70, 45], 233 => [7.5, 47, 26]}

# define sensor mapping for 2 sensors
my_weather_bricklet.config['sensormap'] = { 163 => 'livingroom', 202 => 150 }
=> {163 => "livingroom", 202 => 150}

# retrieve data for all sensors, again
my_weather_bricklet.sensors
=> {"livingroom" => [19.0, 54, 26], 150 => [11.1, 70, 46], 233 => [7.5, 47, 27]}

For weather stations, this would obviously work similarly.

Maybe this helps a bit.

[CChris]

first tests of HomeAssistants Auto-Discovery are working... :)
Now, I need to check, how to do that more dynamically during the program run-time and also publish the sensors state :D





If my code is working so far, I'll try to see if I can redesign this in a way that it could also be used in other programs... or at least, I can create a small documentation on how this could be done...🤔

[CChris]

so, ich bin ein klein wenig weiter :)
Die Auto-Erkennung funktioniert zwar noch nicht so zuverlässig, wie ich es gerne hätte ... das kann aber ggf. auch an meinem System liegen, da ich die Sensoren in HA entsprechend oft gelöscht und neu angelegt habe... Der nächste durchlauf wird daher mal mit einer "frischen" Datenbank sein ^^

Im Moment ist nur eine kleine Handvoll an alten Sensoren im Code umgesetzt... weitere werden folgen, diese kann ich aber mangels Hardware selber kaum testen.

Für jeden Brick & jedes Bricklet wird ein eigenes "Device" in HomeAssistant angelegt


Jedes Device ist dabei um die Information der UID - sowie, wenn vorhanden der UID des Bricks, an welches es angeschlossen ist benannt.
Hier ist erkennbar, dass das Humidity Bricklet (eGQ), der MasterBrick (6qCxXx), das Temperature Bricklet (Temp2) und das Temperature IR Bricklet (zY2) jeweils am Master Brick (6m9VR4) angeschlossen sind.


Diese Unterscheidung wird ggf. später notwendig, sollten mehrere eigenständige Stapel genutzt werden.
Ob meine Software damit überhaupt umgehen kann, habe ich noch nicht getestet - der Fokus liegt im Moment nach wie vor auf einer rudimentären Funktionsweise...

Jedes Device liefert informationen zur Installierten Firmware Version sowie der Hardware-Revision des Bricks / Bricklets.
Ebenso werden die entsprechenden Sensor-Entitäten angelegt, wobei auch diese zur Identifizierung die UID mit im Namen tragen.

Die Sensoren werden einmal bei der Enumerierung mittels .getXyz() abgerufen - danach über Callbacks, wenn sich der Wert ändert.
Im Moment gibt es allerdings noch kleinere Probleme mit dem Sensor-Status direkt nach der Enumerierung... hier muss ich noch ein wenig arbeiten, da es ggf. notwendig ist, nach der Enumerierung den Stapel einmal zu resetten.
Vermutlich irgend ein Timing Thema... ?!

Eines der größten Probleme wird wohl sein, Aktoren hinzuzufügen.
Mein Programm ist im Moment darauf ausgelegt, die Daten abzurufen und an HA zu schicken.

Das funktioniert natürlich nicht, wenn eine eigene Programm-Logik vorhanden sein soll - oder aber, wenn aus HA heraus z.B. der Status eines Dual_Relay geändert werden soll...
Hier wäre es zwar prinzipiell möglich, auf "eingehende" MQTT Nachrichten zu hören und dann entsprechende Aktionen auszuführen, da es sich aber stand jetzt noch nicht um eine eigene Integration für HomeAssistant handelt, können keine Steuerkomponenten hinzugefügt werden, welche das Automatisiert machen.

Bei einer eigenständigen Integration würde sich auch der Umweg über MQTT erübrigen.
Vielleicht gelingt es mir aber doch noch irgendwann, eine "halbwegs" brauchbare Integration zu machen...?