Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Ankündigung
Einklappen
Keine Ankündigung bisher.
MQTT Subscribe Server(LBS19001052) Beispiel 1Wire-owfs-ioBroker -MQTT-Server-Edomi
Hi Carsten,
ich habe noch nicht ganz verstanden, warum es architektonisch besser ist, wenn ein Python Script die 1-wire Sensoren ausliest und dann per MQTT an Edomi sendet, im Gegensatz zum Auslesen direkt durch EDOMI. Ich würde es verstehen, wenn OWFS selbst eine MQTT Schnittstelle anbietet, denn dann käme es ja out-of-the-box für das gesamte 1-wire Netz, aber so ist es nur eine Verlagerung, oder hab ich da jetzt was missverstanden?
Grüß euch,
Also ich habe 1wire auch vom Edomi Server entfernt, da dieser damit ziemlich schnell gedenkpausen einlegt und einfach hängen bleibt. Habe ca. 60 1wire Sensoren.
Ich mache jedoch auch nicht den Zwischenschritt über mqtt, sonder Speise die Temperaturen direkt ins knx ein. Somit kann diese Edomi ohne Hänger verwenden.
die bisherige Lösung mit den OWFS-LBS war und ist klasse, weil absolut stabil und verlässlich. Hänger hatte ich nie (derzeit 35 Sensoren).
Aber...zwei Punkte sehe ich architektonisch zur Verbesserung:
Harmonisierung der Protokolle; ich möchte nach Möglichkeit (d.h. wo sinnvoll machbar) neben nativ (http/REST/API) nur noch MQTT nutzen als etablierte, stabile, verlässliche, performante und schlanke Lösung = Industrie-Standard
Reduzierung von Komplexität und Abhängigkeiten
Beide führt zu KISS: Keep it simpel stupid
Zu Punkt 1 will ich möglichst viele remote-Quellen darüber laufen lassen (z.B. diverse ESP8266 im inbound/Sensoren und outbound/Aktoren). Alles schön einfach, weil alles gleich ist. Ich mag Diversifikation, aber hier im technischen Kontext finde ich "einfältig" = "nur 1 Fall" am besten...
Vor allem der 2. Punkt hat aber reale Wirkung: Jede zusätzliche Installation abseits des edomi-Standards erhöht für mich die Fehlerquellen und vor allem: Wenn sich an der Quelle etwas ändert, dann weiß vor allem die Quelle am besten, was dort zu tun ist. Am besten genau nur dort. Wenn es also irgendwann mal Änderungen an 1-wire gibt oder OWFS (oder wie auch immer die Bibliothek morgen für 1-wire heißt), dann kümmere ich mich genau dort quellnah darum. Nur dort. Und dort hat man auch alle Optionen. Und keine Bibliotheken-Updates im edomi oder Abhängigkeiten. Wenn es also an irgend einem Atom unserer durchaus komplexen LAN-IT-Welt Änderungen gibt (1-wire, MikroTik, PV-Anlage, FritzBox,..), muss ich immer möglichst nur an 1 Stelle ändern/updaten, nicht an 2. In edomi kommt im schlimmsten Fall nur nichts mehr an, erkenne das verlässlich und generiere eine Warn-Mail.
Das Prinzip versuche ich beim Umzug-in-progress meiner 1.64-PROD auf die künftige 2.xx-PROD so weit wie sinnvoll möglich durchzuziehen. Bisher komme ich mit MQTT und MikroTik (kritische Komponente und MQTT an Quelle keine Option) hin. Aber ich bin noch am Umziehen und werde im Zuge dessen vielleicht noch weitere Bibliotheken letztlich nicht gänzlich herumkommen...
Dafür fällt MQTT hoffentlich irgendwann weg, wenn MQTT direkt von edomi unterstützt wird.
VG,
Carsten
Zuletzt geändert von saegefisch; 03.08.2020, 15:15.
Auch wenn es mein erstes Python ist - so funktioniert es bereits; ist ja auch keine Raketenwisschaft. Für jedwede konstruktive Kritik bin ich dankbar, bestimmt kann man das ein oder andere besser lösen in python.
Und natürlich ist es hoffentlich anderen mit den gleichen Zielen dienlich. Jetzt muss es sich mal eine Weile beweisen, dass es so stabil ist, wie die bisherige OWFS-LBS-Lösung... Dann kann jeder mit 1-wire selber entscheiden, welcher Weg sinnvoller erscheint; mit dem ioBrocker sind es nun 3 Optionen:
Code:
#!/usr/bin/env python
# coding: utf-8
import paho.mqtt.client as mqtt
import datetime
from pyownet import protocol
# The callback for when the client receives a CONNACK response from the server.
def on_connect(client, userdata, flags, rc):
print("Connected with result code "+str(rc))
# === Publisher ===
# >>>> Open with TLS + user/PW
client = mqtt.Client()
client.on_connect = on_connect
client.tls_set('/etc/ssl/meineca/cacert.pem')
client.username_pw_set(username="edomi", password="MK6wpXLg_4uxJs")
client.connect("HAL-30.int", 8883, 60)
# >>>>Workload
#
# >> open connect to 1-wire (owserver)
owproxy = protocol.proxy(host="localhost", port=4304, persistent=False, verbose=False)
# get data
topic_pre = '1wire'
for sensor in owproxy.dir(slash=False, bus=False):
try:
type = '/temperature'
val = float(owproxy.read(sensor + type))
topic = topic_pre + sensor.replace(".", "/") + type
client.publish(topic, val)
temp = "{0:.2f}".format(val)
except protocol.OwnetError:
temp = ''
try:
type = '/humidity'
val = float(owproxy.read(sensor + type))
topic = topic_pre + sensor.replace(".", "/") + type
client.publish(topic, val)
hum = "{0:.6f}".format(val)
except protocol.OwnetError:
hum = ''
try:
type = '/vis'
val = float(owproxy.read(sensor + type))
topic = topic_pre + sensor.replace(".", "/") + type
client.publish(topic, val)
vis = "{0:.6f}".format(val)
except protocol.OwnetError:
vis = ''
try:
type = '/VDD'
val = float(owproxy.read(sensor + type))
topic = topic_pre + sensor.replace(".", "/") + type
client.publish(topic, val)
vdd = "{0:.6f}".format(val)
except protocol.OwnetError:
vdd = ''
try:
type = '/VAD'
val = float(owproxy.read(sensor + type))
topic = topic_pre + sensor.replace(".", "/") + type
client.publish(topic, val)
vad = "{0:.6f}".format(val)
except protocol.OwnetError:
vad = ''
# For tests with output
# print('{0:<17} {1:<7} {2:>7} {3:>7} {3:>7} {5:>7}'.format(sensor, temp, hum, vis, vdd, vad))
# TS as publisher-alive-indicator for subscribers
client.publish("1wire/ts_utc", str(datetime.datetime.utcnow()).split('.')[0])
# >>>> Close connections
client.disconnect()
# ============================================
# pyownet can be considered a replacement for ownet (which can be found in module/ownet/python in the owfs source tree). The main reason for writing PYONET code was
# the observation that the ‘official' ownet has an incomplete set of features, it is not maintained anymore, and that there is no support for Python3.
# - OW -> http://owfs.sourceforge.net/owpython.html
# - PYOWNET -> https://pyownet.readthedocs.io/en/latest/protocol.html | https://pypi.org/project/pyownet/
Ablage zum Beispiel hier: /usr/local/bin/1wire2mqtt.py
Eintrag in /etc/crontab für 2-minütlichen Aufruf: # Run frequently to publish all available values from 1-wire via MQTT
*/2 * * * * root /usr/bin/python /usr/local/bin/1wire2mqtt.py
in edomi:
Parser E2 = "1wire/#"
Parser E6 = z.B. "28/065BED060000/temperature"
Den timestamp (oder jeden anderen Wert) per Watchdog prüfen und bei Ausbleiben z.B. nach 10min Warn-Mail, nach 2h Alarm-Mail senden. Am besten notiert man in der Mail bereits seine Erfahrungen, wie man das Problem schon mal gelöst hat.
So bleibt ein Ausbleiben/Instabilität der Lösung nicht unerkannt und im Fehlerfall hat man die Anleitung direkt auf dem smartphone und kann ggf. jemandem Zuhause zur Lösung anleiten.
Jetzt muss es sich nur gegen die bisherige Lösung beweisen... ich bin gespannt... Update 05.08.2020: Bis jetzt sehr stabil, der Watchdog musste noch nicht bellen...
Wer könnte da nur auf die Idee kommen, das über eine zusätzliche ioBrocker-Komponente laufen lassen zu wollen... mqtt.JPG
Zuletzt geändert von saegefisch; 05.08.2020, 20:58.
da ist man mal zwei Wochen im Urlaub, schon hast du in 3 Tagen alles fix und fertig. Respekt!
Da kann ich ja nur noch ergänzen und meine Ansätze informativ nochmal beitragen.
Beim OWFS habe ich mir angewöhnt die Sensoren mit einem Alias zu versehen.
Dadurch spare ich mir in nachgelagerten Anwendungen das 28.55ddff... in konkrete Sensorstandorte "umzudenken".
Diese Alias Datei heißt, bzw. liegt in /etc/ow-alias.
Meine sieht dabei wie folgt aus:
Da ich für meine Heim-IT die Monitoringlösung CheckMK verwende, habe ich die Abfrage nicht über Cronjob erledigt, sondern über den CheckMK-Agenten der ohnehin jede Minute läuft.
Mein Script gibt daher nicht nur die Werte an MQTT weiter, sondern auch per Textausgabe auf der CLI im CheckMK local check Plugin Format aus.
Im CheckMK sieht der Graph dann etwa so aus:
Das Script selbst hat keine Sicherheit eingebaut was die Verbindung zum MQTT Broker angeht!
Das komplette Segment (inkl. Edomi) hängt ohnehin in einem separaten Firewall Segment.
Das natürlich auch um die Geräte im Hausautomatisierungs-LAN Segment (vor allem den KNX Router!) vor zu viel Netzwerkballast (ARP, Broadcasts, sonstiger non-KNX-Multicast, ...) zu schützen.
(Stichwort: Eigene Broadcast Domain)
Aber das ist ja ein anderes Thema.
In meinem Script treffe ich gleich eine Vorauswahl an Sensortypen und behandle nur die für mich interessanten.
Auch einfache Umrechnungen, wie z.B. für den VOC Sensor von tm3d, erledige ich direkt dort.
Nun aber genug gelabert - Hier der Code den ich verwende:
Leider behält der Editor hier die eingerückten Zeilen nicht bei.
Hier das Python Script zum herunterladen: maxim_onewire.txt
Der Code ist bestimmt für einen Python Profi vom Aufbau her lächerlich. Dafür vom ungeübten Python-Gelegenheitsuser 100% Handarbeit ;-)
Wie gesagt, ist für mich in meinem Umfeld eine sinnvolle Lösung - kann sich bei jedem anderen natürlich als unbrauchbar entpuppen.
Da die Vorarbeit mit den Alias nun gemacht ist, kann ich in Edomi wunderbar mit Sensornamen arbeiten, statt dem HEX ID-Wert.
Bilder sagen mehr als viele Worte: edomi_mqtt.png
Da mein Abonnement hier mit # alles umfasst, habe ich noch einen Regexp Filter gesetzt, auf die Werte die mich interessieren:
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar