Zigbee, Hardware, kompatibel,

[udo1toni]

Gewöhnlich sollte openHAB die korrekte Einheit automatisch wählen (immer vorausgesetzt, Du hast alles so konfiguriert, wie sich die Entwickler das ausgedacht haben...)

Beispiel:


Channel ist vom Typ number und liefert die Einheit mit (°C)
Daraus folgt: Item sollte sehr dringend vom Typ Number:Temperature sein. (in OH4 nicht zwingend, aber in der Doku steht schon, dass es zukünftig zwingend wird)
Item Type Number:Temperature bedeutet unter OH4: Es muss zwingend in den Metadaten die gewünschte Einheit konfiguriert werden (Metadaten Unit - gewöhnlich wird man in Deutschland °C wählen). Die Einheit darf nur einmalig festgelegt werden, und zwar am besten gleich zu Beginn.
Die Unit bestimmt, in welchem Format/Einheit der Wert gespeichert wird. Wenn man also Unit später ändert, so gibt es z.B. in Charts Sprünge und auch in Rules "mit ohne Einheit" könnte das Auswirkungen haben. Heißt: natürlich kannst Du auch im Nachhinein noch die Unit anpassen, aber mindestens musst Du Dich dann nicht wundern, dass Charts komisch aussehen. Es ist dann meist sinnvoll, die Persistence für dieses Item zu löschen, damit die Daten wieder konsistent sind.
Im Gegensatz zur Unit kann die State Description (bzw. deren Pattern) jederzeit nach Herzenslust verändert werden.

Wenn Du in einer Rule eine nackte Zahl an ein Number:Temperature Item sendest (also mit .sendCommand oder .postUpdate), wird openHAB die in Unit angegebene Einheit anhängen.

[oh73]

wenn wir den Udo nicht hätten!

kaum macht man es halbwegs richtig, und schon funktioniert es!

hier war sendCommand das Zauberwort.

nur mit der Unit in den Metadateien hab ich noch so meine Probleme,
weshalb ich die Unit auch gerne schon mal weg gelassen habe.

ich arbeite ja sehr viel mit dem Habpanel,
wenn ich da zb.

Code: Alles auswählen

<div>soll : <b>{{itemValue('soll_Hornbach')}}  </b> </div>

angebe, bekomme ich bei ganzen Zahlen nicht die Nachkommastelle angezeigt, in der Sitemap schon!

deshalb lass ich die Unit gerne weg und schreibe dann im Habpanel

Code: Alles auswählen

<div>soll : <b>{{"%.1f" | sprintf:temValue('soll_Hornbach')}} °C </b> </div>

so wird die Zahl immer richtig formatiert!

wo ist da der Fehler?
die Unit in den Metadateien hab ich so "%.1f °C" angegeben, ohne die Anführungszeichen, sollte doch richtig sein?

[udo1toni]

Beispiel eines Items als Textdefinition:

Code: Alles auswählen

Number:Temperature aussenTemperatur "Temperatur außen" <temperature> (gMessen) {channel="mqtt:topic:broker:sensor1:temp", unit="°C", stateDescription=""[pattern="%.1f °C"]} 

In diesem Fall liefert der Channel die Temperatur mit UoM an (Einheit ist egal, solange die Einheit eine Temperatur beschreibt)

Was HABPanel betrifft, kann ich allerdings nichts beisteuern, damit habe ich mich nie ernsthaft beschäftigt.

[oh73]

ja, Habpanel ist etwas doof!

ist aber sagen wir mal zu 90 % nur html Code.
und ich lass davon doch nicht ärgern!

schon schwierigere Sachen gelöst,
meine Lösung für "Number:Temperature" im Habpanel richtig formatiert an zu zeigen,

Code: Alles auswählen

<div>soll : <b>{{'%.1f °C' | sprintf:itemValue('soll_Hornbach').split(' °')[0]}}  </b> </div>

einfach mit split das " °C" abschneiden.

das Item dazu,

Code: Alles auswählen

Number:Temperature		ist_Hornbach		"Bad Heizung ist Temperatur [%.1f ]"	<temperature> {channel="deconz:thermostat:00212EFFFF072015:f4ce365acafeb96d010201:temperature", unit="°C", stateDescription=""[pattern="%.1f °C"] }

oder auch nur

Code: Alles auswählen

Number:Temperature		soll_Hornbach		"Bad Heizung soll Temperatur [%.1f ]"	<temperature> {channel="deconz:thermostat:00212EFFFF072015:f4ce365acafeb96d010201:heatsetpoint" , unit="%.1f °C" }

[mad-mike]

Irgendwie verstehe ich es noch nicht so ganz mit dem Stick.
Also muss der Stick auch die Hardware Funktion erkennen? Oder macht das openHAB?

Ich habe mir ein sonoff Taster bestellt. Habe gesucht und gefunden.

Angezeigt wurde ein unbekanntes Gerät.

Offline..

Zigbee binding: Node has not completed discovery

Gab's als Hinweis.

Nun ich hatte ja auf gut Glück versucht so ein Taster zu kaufen, dachte Stick ist von sonoff, nimmt man auch den taster von denen. War mir bewusst das es eventuell scheitert.

Naja zwischenzeitlich musste der Hund raus. 1,5 später schaue ich, war der Taster auf einmal online, und hatte auch alle auswählbare Channel.

Taster funktioniert...

Also, kann ich jetzt noch Mal ein Bosch Aktor versuchen und einfach warten...?

[oh73]

Code: Alles auswählen

Also, kann ich jetzt noch Mal ein Bosch Aktor versuchen und einfach warten...?

nein, Bosch funktioniert zu 99% nicht, nur mit dem Bosch Gateway!

[mad-mike]

nein, Bosch funktioniert zu 99% nicht, nur mit dem Bosch Gateway!

,

Stimmt, Habs noch mal mit dem zigbee zwischenstecker und mit dem Licht/ Rollo II modul versucht.

Auch mit wartezeit gabe keine Veränderung...

[oh73]

ist zwar schon ein Jahr her, aber hab jetzt doch mal einen gebrauchten SonOff iHost gefunden.

erste Versuche zeigen das das Teil gar nicht soo schlecht ist.
hab erst mal 3 Bewegungsmelder und 3 Steckdosen angelernt, alles mit dem Pc und Browser, App und Cloud braucht man nicht!

jetzt wollte ich aber auch einen Datenaustausch mit openhab haben.
ist mir auch zum Teil gelungen, allerdings bisschen über Umwege! ob das noch besser geht?

also vom iHost zu openhab über node-red und MQTT.
die Daten kann ich dann mit openhab ohne größere Probleme lesen!

anders herum, von OH zum iHost komme ich mit MQTT nur bis zu node-red aber nicht zum iHost!

aber da gibt es noch einen anderen weg über die Rest-Api vom iHost.
funktioniert soweit auch, nur bin ich noch nicht sicher ob alles so richtig ist?

Problem wenn ich zB. einen Schalt-Befehl zum iHost schicke, kommt ja die Statusänderung über MQTT zurück!
zeigt mir bisher keine Fehler im Log an, hab aber bedenken das ich vielleicht eine Endlos Schleife erzeuge??

hab zwar versucht das mit einer Rule ab zu fangen, aber ob alles richtig ist?

Beispiel Thing:

Code: Alles auswählen

Type switch : iHost_Ikea	 "iHost_Ikea"  		[ stateTopic="node-red/out/Ikea" , transformationPattern="JSONPATH:$.payload.power.powerState",
															commandTopic="node-red/in/Ikea",
															on="on", 							
															off="off"

Beispiel rule:

Code: Alles auswählen

rule "empfange Ikea Status"
when
	Item iHost_Ikea_state changed
then
	if ( iHost_Ikea_state.state != iHost_Ikea.state  ) {
		iHost_Ikea.postUpdate(iHost_Ikea_state.state)
		
	}	
end


rule "sende Ikea Status"
when
	Item iHost_Ikea changed
then
	
	if ( iHost_Ikea_state.state != iHost_Ikea.state  ) {
		if ( iHost_Ikea.state == ON) {
			executeCommandLine("sh","/home/scripts/Ikea_ein.sh")
		}
		if ( iHost_Ikea.state == OFF) {
			executeCommandLine("sh","/home/scripts/Ikea_aus.sh")
		}
	}
end

Beispiel Items :

Code: Alles auswählen

Switch  iHost_Ikea_state	"iHost Ikea status von iHost"			{ channel="mqtt:topic:node_red:iHost_Ikea" }
Switch 	iHost_Ikea			"iHost Ikea Schalter "

[udo1toni]

Eigentlich solltest Du nur ein Item benötigen.

Die Verbindung zwischen Items und Channels ist n:m, man kann beliebig viele Items mit beliebig vielen Channels verlinken - auf beliebige Art.
Hier wären der Channel zum Senden des Befehls und der Channel zum empfangen des Status die zwei zu verlinkenden Channel. Da mqtt zum Senden nicht funktioniert, konfigurierst Du diesen Channel ReadOnly und lässt das commandTopic weg. Für die Gegenrichtung kannst Du das exec Binding verwenden, wobei es sich anbietet, nur ein Script zu verwenden und dieses so zu gestalten, dass man ON bzw. OFF als Parameter übergeben kann (in bash Scripten kann man $1 für den ersten Paramer verwenden).
openHAB sollte Befehle nur senden, wenn openHAB auch einen Befehl senden soll Deine 2. Rule triggert auf changed, das ist verkehrt. Stattdessen wäre received command als Trigger korrekt (und innerhalb der Rule liefert dann receivedCommand den eigentlichen Befehl, also bei einem Switch Item ON bzw. OFF.
Aber wie gesagt, eigentlich brauchst Du gar keine Rule, selbst wenn Status und Befehl über unterschiedliche Addons gehen.

[oh73]

Danke, man lern immer noch dazu

die Idee mit der Parameter Übergabe und nur ein Script kam mir heute Morgen beim Frühstück auch schon!

hab das mal bisschen umgebaut, mit received command als Trigger könnte das schon funktionieren,
nur receivedCommand liefert mir den Status ON, OFF in Großbuchstaben, brauche den Status zum senden aber in Kleinbuchstaben!

mal sehen was ich da noch machen kann?
auch noch eine weitere Idee, wenn ich schon mal dran bin, die Schalter in eine Gruppe zusammen fassen und dann die Gruppe abfragen.

müsste ich schon hin kriegen, nur so aus dem Kopf funktioniert das bei mir nicht.
hab aber immer ein paar Muster die ich dann anpassen kann !