Fronius Wattpilot

Einrichtung der openHAB Umgebung und allgemeine Konfigurationsthemen.

Moderatoren: seppy, udo1toni

klaus1
Beiträge: 89
Registriert: 11. Jan 2022 13:48

Re: Fronius Wattpilot

Beitrag von klaus1 »

ok. die lösung über externen ocpp server ist auch keine Dauerhafte Lösung.

ich greife nochmal die MQTT Lösung von wattpilotshell auf.
Lt. Wattpilotshell config muss ich nur den Wattpilot url + passwort sowie die MQTT Host Url angeben und starten.
Das hätte ich.
Auf der openhab (3) seite habe ich einen MQTTBroker und ein GenericMQTTThing angelegt.
Wie komm ich jetzt zu den Daten von WattpilotShell ?
Eine Art Discovery hat ja der MQTTBroker auf openhab Seite...
mosquitto ist installiert am Raspberrypi.
danke

Benutzeravatar
udo1toni
Beiträge: 13867
Registriert: 11. Apr 2018 18:05
Answers: 222
Wohnort: Darmstadt

Re: Fronius Wattpilot

Beitrag von udo1toni »

Das mqtt Protokoll arbeitet mit einer Zentrale, das ist mosquitto (es gibt auch andere Implementierungen, aber mosquitto ist im Heimbereich sicherlich die populärste).
Der Broker (also mosquitto) "handelt" mit Nachrichten, wobei die Nachrichten nach Themen sortiert werden. Ein Client kann seine Nachrichten unter einem oder auch mehreren "Topics" "publizieren", er sendet sie aber nur zum Broker.
Ein anderer Client kann Topics abonnieren und bekommt vom Broker alle Nachrichten zu den abonnierten Themen mitgeteilt.

wattpilotshell nutzt also das mqtt Protokoll und sendet seine Nachrichten an bestimmte Topics an den Broker.
openHAB wiederum muss diese Topics abonnieren.
Falls wattpilotshell sich an einen Standard für Autodiscovery hält, der von openHAB unterstützt wird, reicht es, in openHAB eine mqtt Bridge zum Broker einzurichten (* und unterhalb dieser Bridge ein Autodiscovery durchzuführen (Scan Knopf).
Sollte wattpilotshell hingegen kein Autodiscovery unterstützen - was der Normalfall sein dürfte - dann musst du das benötigte Thing von Hand anlegen (ein generic mqtt Thing und Channel pro verwendetem Topic).

(* die Bridge ist nur der mqtt Client, NICHT der Broker, auch wenn man die Bridge in openHAB gerne als Broker bezeichnet - das bezieht sich aber auf die Verbindung zum Broker, nicht auch die Funktion.
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet

klaus1
Beiträge: 89
Registriert: 11. Jan 2022 13:48

Re: Fronius Wattpilot

Beitrag von klaus1 »

Danke für die Hilfe.
Ich hab jetzt folgendes erledigt:
MQTT Broker angelegt, diesen als Bridge verwendet für das Generic MQTT Thing.
Dort einen Channel angelegt und ein Number Item angelegt mit dem Topic, das ich rausgefunden habe, das standardmäßig gesendet wird: "wattpilot/#".
das liefert folgende topics:
wattpilot/{myserial}/messages/fullStatus
wattpilot/{myserial}/messages/deltaStatus

Jetzt beomme ich ein JSON Objekt retour mit den Werten, wo ich mit JSONPATH ($.status.car) bspw den Wert rausbekomme, ob das Auto angeschlossen ist und das im Item binden kann.

das bringt mir jetzt schön den Wert 4 bspw. als Number ins Item.
Wie kann ich zusätzlich noch eine Map drauf legen ? weil unter Pfofile im Item kann ich entweder Standard, Folgen, MAP, JSONPATH oder JS verwenden.
(hoffentlich nicht noch ein Item mit MAP)

1 = "no car"
2 = "charging"
3 = "ready"
4 = "complete"
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Benutzeravatar
udo1toni
Beiträge: 13867
Registriert: 11. Apr 2018 18:05
Answers: 222
Wohnort: Darmstadt

Re: Fronius Wattpilot

Beitrag von udo1toni »

Nope.
Also erst mal legst Du im Thing Channel an und verlinkst anschließend Items mit den Channels. Ich weiß, Korinthenkacker, aber hilft ja nichts, es ist sehr wichtig den Unterschied zu verstehen.
Dann die zu abonnierenden Topics: Keinesfalls solltest Du einen Joker (#) verwenden. Der Joker ist in Ordnung, um in MQTT.fx oder MQTT Explorer alle Topics angezeigt zu bekommen. Dort werden die Topics dann auch getrennt angezeigt.
In openHAB ist die Zuordnung des Topics zum Channel aber fix, und fullStatus ist nun mal was anderes als deltaStatus.

Stattdessen legst Du zwei Channel an, die jeweils das vollständig ausgeschriebene Topic enthalten.

Jetzt hast Du zwei Möglichkeiten: Entweder, du definierst für jeden Wert, den Du extrahieren willst einen eigenen Channel, oder Du verwendest jeweils einen Channel pro JSON Objekt, welchen Du dann mit beliebig vielen verschiedenen Items verlinken kannst.

Vorteil ist hier, dass Du nur einen (oder in diesem Fall zwei) Channel anlegen musst.
Nachteil (und der kommt hier voll zum Tragen): Du musst JSONPATH zwingend im Link verwenden.

Im vorliegenden Fall (weil Du ja gerne ein Mapping der Werte haben möchtest) musst Du das abwägen.
Wichtig hierbei: Der Link ist nicht die einzige Stelle, an der Du ein Mapping vornehmen kannst, das geht auch noch später, nämlich bei der Darstellung des Wertes. Der Unterschied: findet das Mapping im Link (oder vorher) statt, so steht der gemappte Wert im Item. Du musst also ein String Item verwenden, um die Strings zu speichern. Willst Du in einer Rule auf den Zustand des Items reagieren, so musst Du dort auf den gemappten String prüfen. Nimmst Du stattdessen das Mapping erst in der Anzeige vor (also "hinter" dem Link) so landet der Zahlenwert im Item. Du kannst ein Number Item verwenden, in einer Rule kannst Du einfach auf den Zahlenwert vergleichen. Dafür musst Du allerdings an jeder Stelle, an der Du den gemappten Wert anzeigen willst, das Mapping einbinden (das geht aber auch zentral).
Ich möchte empfehlen, dass Du ein Number Item verwendest und den Zahlenwert speicherst. Das Mapping trägst Du dann in den Metadaten des Items ein, und zwar unter state description. Im Feld Options hinterlegst Du einfach die Liste der Mappings, was den dargestellten Wert direkt in den Text ändern sollte, und zwar quasi überall. Es ist aber möglich, dass in der Liste der Items oder auch wenn man den Channel anschaut, hier der Zahlenwert angezeigt wird. openHAB berücksichtigt die State Description aber definitiv in den Pages und den Sitemaps. Die Itemliste und überhaupt der gesamte Administrationsbereich ist nicht für den normalen User gedacht, sondern (der Name sagt es ja) nur zur Administration des Systems.
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet

klaus1
Beiträge: 89
Registriert: 11. Jan 2022 13:48

Re: Fronius Wattpilot

Beitrag von klaus1 »

bekomme aktuell im openhab log noch ein warning:
2023-02-20 09:45:14.854 [WARN ] [ofiles.JSonPathTransformationProfile] - Could not transform state '{"type":"deltaStatus","status":{"rfb":1700,"rssi":-41,"ehs":293852,"efh":120368,"efh32":120368,"efh8":82320,"utc":"2023-02-20T08:45:13.849","loc":"2023-02-20T09:45:13.850 +01:00","rbt":683334345,"nrg":[231,231,233,0,0,0,0,0,0,0,0,0,0,0,0,0],"fhz":49.852,"tpcm":[17,0,3,2,0,0,0,0,31,0,53,1,0,69,72,0,0,0,0,0,0,0,6]}}' with function '$.status.car' and format '%s'

hätte da ein item carConnected mit JSONPATH $.status.car das item liegt auf datentyp Number : Point
klappen tut alles, nur das warning ist interessant.
heißt dass, dass es hier in dem aktuellen topic des deltaStatus das item nicht gibt? (bekomme das beim anderen topic, und bei dem deltaStatus aber nur bei Änderung).
Falls es sich nicht beheben lässt. wie kann ich das im openhab log entfernen (WARNINGS). besser wäre aber die Ursache zu finden.


UND: wie schaff ich den auto startup von wattpilotshell beim hochfahren vom raspberrypi ?
my try: /etc/rc.local:
export MQTT_ENABLED=true
export HA_ENABLED=false
export MQTT_HOST=192.168.1.xx
export WATTPILOT_HOST=192.168.1.xx
export WATTPILOT_PASSWORD=xxxx
wattpilotshell

exit 0
im log passts, prozess läuft leider nicht nach login. :-(
danke

Benutzeravatar
udo1toni
Beiträge: 13867
Registriert: 11. Apr 2018 18:05
Answers: 222
Wohnort: Darmstadt

Re: Fronius Wattpilot

Beitrag von udo1toni »

Wie gesagt, Du musst schon das richtige Topic verwenden. Das JSON sieht lesefreundlich formatiert so aus:

Code: Alles auswählen

{
	"type": "deltaStatus",
	"status": {
		"rfb": 1700,
		"rssi": -41,
		"ehs": 293852,
		"efh": 120368,
		"efh32": 120368,
		"efh8": 82320,
		"utc": "2023-02-20T08:45:13.849",
		"loc": "2023-02-20T09:45:13.850 +01:00",
		"rbt": 683334345,
		"nrg": [
			231,
			231,
			233,
			0,
			0,
			0,
			0,
			0,
			0,
			0,
			0,
			0,
			0,
			0,
			0,
			0
		],
		"fhz": 49.852,
		"tpcm": [
			17,
			0,
			3,
			2,
			0,
			0,
			0,
			0,
			31,
			0,
			53,
			1,
			0,
			69,
			72,
			0,
			0,
			0,
			0,
			0,
			0,
			0,
			6
		]
	}
}
Und Du kannst gut sehen, dass es schlicht keinen Datenpunkt status.car gibt.
Es kann natürlich sein, dass der delta Status den Datenpunkt status.car nur ab und zu enthält.
Aber wie oben beschrieben solltest Du keinesfalls im angegebenen Topic den Joker verwenden.
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet

klaus1
Beiträge: 89
Registriert: 11. Jan 2022 13:48

Re: Fronius Wattpilot

Beitrag von klaus1 »

Hallo,
Verwende jetzt beide topics.
Habe aber immer das Problem das nur ab und zu die values wie car kommen.
Laufen dann in Warnings die ich mit log42 ausblenden.

Benutzeravatar
udo1toni
Beiträge: 13867
Registriert: 11. Apr 2018 18:05
Answers: 222
Wohnort: Darmstadt

Re: Fronius Wattpilot

Beitrag von udo1toni »

Wie holst Du die Werte (an welcher Stelle)?
Kurz ausgeholt: es gibt drei verschiedene Stellen, um per JSONPATH einen einzelnen Wert aus einem JSON Objekt zu extrahieren. Von hinten nach vorne:
1. Du speicherst das vollständige Objekt in einem String Item ab. Dann manipulierst Du das Display mit JSONPATH, so dass immer nur ein bestimmtes Datum (Einzahl von Daten...) angezeigt wird. Vorteil: Du brauchst nur ein Item für ein ganzes Bündel an Informationen. Nachteile: Die Information liegt nicht separat vor. Wenn Teile der Informationen nicht ständig vorliegen (wie bei Dir wohl der Fall) hast Du Pech, da immer nur der aktuelle Inhalt dargestellt wird.
2. Du speicherst die einzelnen Daten in separaten Items. JSONPATH wird dabei im Link angegeben. Du verlinkst alle Items mit dem selben(!) Channel, der zwingend ein String Channel sein muss. Vorteil: Du brauchst nur einen Channel pro Topic. Nachteil: Im Link kannst Du nur eine der Transformations nutzen, weshalb Du bei fluktuierenden Daten (siehe 1.) genauso aufgeschmissen bist.
3. Du nutzt für jedes Datum einen eigenen Channel. Die Transformation geschieht bereits im Channel. Nachteil: Du musst je nach Anzahl gewünschter Daten aus einem JSON Objekt ziemlich viele Channel definieren, die sich lediglich im JSONPATH unterscheiden, ansonsten aber identisch sind (nun ja, bis auf die ID natürlich). Vorteile: Innerhalb der stateTransformation kannst Du mehrere Transformations miteinander verketten. Dadurch kannst Du verhindern, dass es zu einem Fehler kommt, wenn ein Datum nur zeitweise zur Verfügung steht. Außerdem kannst Du jedem Wert gleich noch die korrekte Einheit mitgeben, so dass Du die Vorzüge von UoM (Units of Measurement) genießen kannst.

Ich nehme an, dass Du bisher mit Option 2 gearbeitet hast, oder vielleicht tatsächlich bisher nur einen einzigen Wert extrahiert hast. Für die Nummer mit car sähe ein passender Channel so aus:

Code: Alles auswählen

Type number: car [stateTopic="wattpilot/fullStatus",stateTransformation="REGEX:(.*car.*)∩JSONPATH:$.status.car"]
Die Notation ist die in einem *.things File, das funktioniert aber exakt genauso auch über die UI. Der Schlüssel ist hierbei die Verknüpfung der beiden Transformations über das ∩. Das Symbol findet sich im Hilfstext zum Feld, in dem die stateTransformation angegeben wird. Da es über die Tastatur nicht direkt eingegeben werden kann, empfehle ich immer den Weg über die Zwischenablage. Es gibt im Unicode Zeichensatz mehrere Zeichen, die diesem zum Verwechseln ähnlich sehen. Dieses hier hat den Unicode 2229 und hört auf den Namen Intersection (in der Zeichentabelle in Windows fälschlich mit Durchschnitt übersetzt, obwohl es das Zeichen für Schnittmenge ist - was auch erklärt, warum es in openHAB verwendet wird).
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet

klaus1
Beiträge: 89
Registriert: 11. Jan 2022 13:48

Re: Fronius Wattpilot

Beitrag von klaus1 »

danke. mein hauptproblem ist derzeit das programm selber. da gibts keinen server mode... d.h. im hintergrund oder beim startup funktioniert das nicht... leider

Benutzeravatar
udo1toni
Beiträge: 13867
Registriert: 11. Apr 2018 18:05
Answers: 222
Wohnort: Darmstadt

Re: Fronius Wattpilot

Beitrag von udo1toni »

Ich weiß jetzt nicht, was Du meinst...
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet

Antworten