PV-Anlage, Shelly's und Hichi IR Lesekopf in Openhab zusammenbringen

[Frank T.]

Hallo zusammen,
ich bin neu hier im Forum. Heiße Frank und komme aus Moers.
Vor ca. 1 Jahr habe ich erst mit einem Balkonkraftwerk angefangen Strom zu produzieren,
mittlerweile sind es 4 Stück gut 5kW peak.
Ich verwende keinen Speicher (noch nicht )
Dafür sind die Module so aufgestellt das von Sonnenaufgang bis zum Sonnenuntergang horizontal optimal ausgerichtet sind.
Das funktioniert soweit recht gut. Wir sind mit den Verbrauch von rund 4000kW auf 1700kW gekommen.
Aber es geht noch recht viel Strom ungenutzt ins Netz.

Nun möchte ich gerne den überschüssigen Strom mit 4 Flächenheizkörper a 400 Watt nutzen.
Im Sommer könnte es dann eine Klimaanlage sein.
Das Ganze soll über openhab gesteuert werden.
Vorhanden ist ein Raspberry pi 4 auf dem bereits openHABian installiert ist.
Die 4 Heizkörper sollen über 4 Shelly Plug s geschaltet werden.
D.h. sind 400 Watt an Überschuss vorhanden -> 1. Heizung ein
Sind dann noch weitere 400 Watt an Überschuss da -> 2. Heizung ein. usw.
Fällt der Überschuss auf < 0 Watt den zuletzt eingeschalteteten Heizkörper aus usw.
Ich hoffe ihr versteht was ich meine.

Der aktuelle Verbrauch/Überschuss soll mit dem Hichi IR Wifi erfasst werden.
Da die Werte sehr stark schwanken soll im Sekundentakt gemessen werden und aus den Messwerten einer Minute ein Mittelwert gebildet werden.
Genial wäre wenn die zuletzt gemessenen Werte einen höhere Gewichtung bekommen -> Trend
Eine Idee ist vorhanden aber die Umsetzung läuft nicht ganz so flüssig!!!

Ein Shelly hab ich irgendwie in openhab eingebunden bekommen und der aktuelle Verbrauch wird mir auch angezeigt.
Aber bereits an der Einbindung des Hichi IR Wifi bin ich gescheitert.

Ich hoffe ihr könnt mir helfen.

Viele Grüße
Frank

[udo1toni]

Herzlich Willkommen im Forum!

Grundsätzlich sollte das möglich sein, ich möchte aber darauf hinweisen, dass es sich hierbei um eine klassische Regelungsaufgabe handelt. openHAB ist KEIN Regelsystem, sondern ausschließlich zum Steuern gedacht. (Wie gesagt - machbar ist das sicherlich dennoch).

Wegen der Einbindung der Hichi IR Wifi: schau mal hier: viewtopic.php?t=7242&hilit=hichi

Der erste Schritt ist also, den Lesekopf an einen mqtt Broker anzubinden. openHAB spricht dann mit dem mqtt Broker.
Wenn Du einen Raspberry mit openHABian Image aufgesetzt hast, kannst Du in openhabian-config direkt mosquitto (OpenSource MQTT Broker) installieren lassen.

Zum Testen empfiehlt sich der MQTT Explorer (kostenlos - im MS-Store verfügbar).
Bei mqtt reden alle Geräte ausschließlich mit dem Broker, alle Geräte sind also Clients. Der Broker vermittelt die Messages (in diesem Fall sind die englischen Bezeichnungen so korrekt, dass man sich nur wundern kann...)
openHAB tritt dann ebenfalls als Client auf und verbindet sich über eine Bridge (mqtt Addon), die Daten landen dann in einem generic mqtt Thing und können entsprechend ausgewertet werden (wie im verlinkten Thread beschrieben).

[frankh]

Hallo Frank,

Ich hatte eine ähnliche Herausforderung . Habe meine Erkenntnisse zusammengeschrieben, damit ich irgendwann selber noch weiß, wo man was machen muss vielleicht hilft dir das ein oder andere bei deiner Lösung. Ich setze den Hichi ohne WLAN ein, es gibt ihn aber auch direkt als Kombi, was einige Arbeit bzgl ESP und Tasmota erspart.
https://frankhoerper.github.io/FranksTe ... ehler.html
Vg

[udo1toni]

Ich habe die Anleitung nur überflogen, ABER ein wirklich fetter Fehler in der Konfiguration ist mir direkt ins Auge gesprungen, das ist das gesetzte Topic und das FullTopic.

Das FullTopic MUSS, damit die mqtt Anbindung korrekt funktioniert, die beiden Variablen %prefix% und %topic% enthalten, das ist nicht optional!
Die Variable %prefix% enthält wahlweise tele, cmnd oder stat, je nachdem, welchen Teil Tasmota gerade anspricht.
Die Variable %topic% enthält das, was bei Topic obendrüber angegeben ist, kann aber auch noch weitere Inhalte haben, (es gibt noch Fallback Topic und Group Topic).

Ich habe bei mir z.B. das FullTopic auf %topic%/%prefix%/ geändert, so dass bei mir im mqtt Baum für jedes Device ein eigener Knoten auf der höchsten Ebene angelegt wird. Gewöhnlich gibt es da nur drei Knoten, eben cmnd, stat und tele, dafür aber unterhalb jedes dieser drei Konten für jedes Device einen eigenen Knoten. Man könnte hier auch noch Geräte zu Gruppen zusammenfassen, z.B. so: Schaltsteckdosen/%topic%/%prefix%/
Nun werden alle Geräte, bei denen dieses FullTopic eingetragen ist in einer Gruppe Schaltsteckdosen zusammengefasst.
Im Topic vergibt man einen eindeutigen Namen, oder zumindest einen im Rahmen des Fulltopics eindeutigen Namen. Auch hier könnte man noch Unterebenen definieren, es erscheint aber sinnvoll, es damit nicht zu übertreiben

Die drei Zweige cmnd, tele und stat haben in Tamota ganz klar definierte Funktionen:

• cmnd ist zum Senden von Befehlen in Richtung Tasmota gedacht. Das entspricht der Eingabe in der Tasmota Kommandozeile.
• stat liefert unmittelbare "Antworten" auf empfangene Kommandos. Nehmen wir das Standard FullTopic und das Topic "device" als Beispiel, dann kann man eine Schaltsteckdose mit cmnd/device/POWER ON dazu bewegen, die Steckdose einzuschalten. Gleichzeitig wird Tasmota mit stat/device/POWER ON und stat/device/RESULT {"Power":"ON"} reagieren.
• Über tele werden zyklisch Daten gesendet.

[Frank T.]

Hallo Frank,

Ich hatte eine ähnliche Herausforderung . Habe meine Erkenntnisse zusammengeschrieben, damit ich irgendwann selber noch weiß, wo man was machen muss vielleicht hilft dir das ein oder andere bei deiner Lösung. Ich setze den Hichi ohne WLAN ein, es gibt ihn aber auch direkt als Kombi, was einige Arbeit bzgl ESP und Tasmota erspart.
https://frankhoerper.github.io/FranksTe ... ehler.html
Vg

@frankh

Hallo Frank,

besten Dank für deine Antwort.
Könnten wir zu dem Thema mal Kontakt per mail oder Telefon zusammen aufnehmen?

Viele Grüße
Frank

[frankh]

Ich habe die Anleitung nur überflogen, ABER ein wirklich fetter Fehler in der Konfiguration ist mir direkt ins Auge gesprungen, das ist das gesetzte Topic und das FullTopic.

guter Hinweis - ist eigentlich auch sehr gut dokumentiert : https://tasmota.github.io/docs/MQTT/#examples
Die ganzen Tasmotas verrichten trotz dieses wirklich schweren Fehlers (!) (bisschen dramatisch ) ihren Dienst - aber wenn der dirty code erstmal tut , was man möchte - dann hält erfahrungsgemäss nichts länger als ein workaround Habe das gestern mal geändert und funktioniert jetzt genauso - aber konzeptionell ordentlich
Wenn ich mir jetzt die Tasmota messages anschaue , dann sendet der Lesekopf auf
volkszaehler/tele/SENSOR
und
volkszaehler/tele/STATE

command brauche ich eigentlich nicht - dazu fällt mir im Moment zumindest kein use case ein.

Was muss ich denn jetzt in dem GenericMQTT channel config fuer die state topic eintragen ? eine tele topic gibt es nicht ? Schadet ja nicht, dass einmal richtig aufzusetzen. Mal sehn, ob und wie meine Konfiguration dann von deinem Vorschlag abweicht.

[udo1toni]

Du darfst nur nicht auf die ähnlichen Begrifflichkeiten hereinfallen.

Tasmota != mqtt != generic mqtt Thing.

In Tasmota gibt es drei Prefixes, eben für Commands, Status und zyklische Status.
Das heißt aber nichts anderes, als dass die Senderichtung von Tasmota zweigeteilt ist.
In mqtt gibt es nur zwei Richtungen, vom Client zum Broker und vom Broker zum Client. Die Topics, welche zum Client gehen, werden vom Client abonniert, die Topics, über die der Client sendet, werden vom Client (gewöhnlich) nicht abonniert.
Und in openHAB wird exakt mqtt abgebildet, kein Tasmota. Es gibt also Topics zum Senden und Topics zum empfangen.
Die Empfangsrichtung wird über stateTopic konfiguriert, die Senderichtung über commandTopic. Wenn ein Channel nur senden soll, wird kein stateTopic konfiguriert, wenn ein Channel nur empfangen soll, wird kein commandTopic konfiguriert.
Und es gibt noch eine Besonderheit, nämlich wenn das stateTopic als Befehl interpretiert werden soll (dann wird der Schalter isCommand aktiviert). Damit wird dann im openHAB Bus bei jedem Update ein sendCommand() ausgelöst. Das ist wichtig, wenn man von mqtt aus per Befehl ein anderes Gerät steuern möchte, welches nicht per mqtt an openHAB angebunden ist, sondern auf anderem Weg. wird das stateTopic als Command gewertet, so reicht es dann, beide Channel an ein Item zu verlinken. Der zweite Channel bekommt das sendCommand mit und reagiert darauf, ganz ohne Rules.
Auf diese Weise könnte man z.B. mit dem Tastereingang eines Shelly eine Hue Lampe direkt schalten, ohne weitere Umwege.

[Frank T.]

Hallo,

für die Installation hab ich mir das Image von openhab.org für den Raspberry mittels etcher geschrieben.
Für die Einrichtung habe ich mir das Video angesehen.
https://www.youtube.com/watch?v=VEagSEx ... Jl&index=1

Der Anfang funktionierte aber bei der "MQTT system broker connection" war es vorbei" im Video bei 16:33 zu sehen.
Diese Einstellung taucht bei mir nicht auf.

Hat sich seit dem Video etwas an der Einrichtung geändert?

Viele Grüße
Frank

[udo1toni]

Das Video ist uralt und ja, es hat sich was geändert. vergiss bitte den Begriff MQTT System Broker komplett.
a) das war so noch nie richtig...
b) das ist schon lange aus openHAB entfernt worden (spätestens in OH3.1, wir sind inzwischen fast bei 3.4).

Stattdessen musst Du mosquitto als Broker einrichten (geht über openhabian-config -> 20 -> 23). Falls Du das schon erledigt hast (ich habe mir das Video jetzt nicht rein gezogen), kannst Du gleich mit der Einrichtung der passenden Bridge weiter machen.
Hast Du das mqtt Addon schon installiert? Prima, dann unter Administration->Einstellungen->Things-> unten rechts plus -> mqtt Binding -> MQTT Broker -> Unique ID auf was sinnvolles setzen (z.B. mosquitto oder broker), Label auf was sinnvolles setzen, als Broker IP kannst Du localhost angeben, alternativ auch 127.0.0.1 oder die reale IP des Host, alle drei Varianten müssen funktionieren. Der Rest der Einstellungen ist optional, falls Du beim Einrichten von mosquitto User und Passwort vergeben hast, musst Du diese Daten natürlich auch eintragen. Es bietet sich an, als ClientID ebenfalls etwas sinnvolles zu setzen, z.B. openHAB3.

wenn mosquitto läuft, sollte die Bridge nach dem Speichern unmittelbar Online gehen. ISt das der Fall, so kannst Du anschließend generic MQTT Things hinzufügen. Immer dran denken, dass Du die Bridge im Thing aktiv auswählen musst, auch wenn es nur eine einzige Bridge für MQTT gibt.

[Frank T.]

Hallo,

Vielen Dank für die schnelle Antwort!
Ich hoffe das ich jetzt weiter komme. Kannst du mir zu dem Thema eine Schritt für Schritt Anleitung oder Video empfehlen. Hätte nicht gedacht, daß selbst ein 1 Jahr altes Video solche Probleme bringt.
Gibt es evtl. Openhab User mit denen man sich Vorort treffen kann?
Wenn noch nie mit dem System gearbeitet habe, finde ich den Einstieg schon heftig.

Viele Grüße
Fr