Tristate Item?

[Bubbleman]

Hallo

Gibt es die Möglichkeit in einem Item drei Stati abzubilden/zu speichern?

Zum einen soll der Status eines Garagentors abgebildet werden: geschlossen/geöffnet/offen
"geschlossen" und "offen" kommt von den Endtastern. Ist keiner betätigt soll der Zustand "geöffnet" abgebildet werden.
Weiterhin will ich den Motor des Garagentoröffners abbilden: dreht links/dreht rechts/steht
Es wäre schön wenn das jeweils in einem Item darzustellen ginge, ich das dann in einem Widget darstellen, und in Rules und Scrips verwursten kann.

Ich habe die Hardware (Wemos D1 Mini mit Tasmota) dazu noch nicht fertig, aber die Signale werden per MQTT in OH3 reinkommen.
Ich muss mich noch tiefer mit Tasmota auseinandersetzen um die "richtigen" Topics bzw. Payload absetzen zu lassen.
Die Endtaster des Tors und die Drehrichtungserkennung des Motors werden jeweils zwei GPIOS am Wemos benötigen. zB:
Pin 1 high + Pin 2 low = Linkslauf
Pin 1 low + Pin 2 high = Rechtslauf
Pin 1 low + Pin 2 low = steht
Dann soll der Payload auch entsprechend lauten und könnte über einen Channel in OH3 auftauchen.

Die eigentliche Frage zielt, wie oben gesagt, aber auf ein "Tristate" Item. Gibts sowas?

Gruß
Thomas

[udo1toni]

Drei Status über ein Item sind so nicht vorgesehen, aber Du kannst natürlich sowohl ein Number Item als auch ein String Item dazu verwenden. Beim Number Item hast Du dann die freie Wahl, was Du nutzt, ob nun -1, 0, 1 oder 5,49 und 112 wichtig ist ja nur, dass Du die Zahlenwerte den verschiedenen Status zuordnen kannst. Gleiches gilt natürlic hauch für das String Item, wobei Du da sogar mit Klartext arbeiten kannst.

[BOP]

Ich habs auch einfach über ein Number Item gemacht.
// Garage_Tor_Position
// 0 = geschlossen
// 1 = öffnet
// 2 = schließt
// 3 = geöffnet
// 4 = Zwischenstellung
// 5 = in Bewegung

Passend dazu dann noch Items für die Sitemap.

[int5749]

Ich habe dies, wie bereits von Udo1Toni empfohlen, über zusätzliche Items und einen String gelöst.

Items

Code: Alles auswählen

Contact Tor_Garage_o 		(cGaragentor)	{channel="knx:device:bridge:xxx:chx"}		//"Tor oben [MAP(de.map):%s]"
Contact Tor_Garage_u 		(cGaragentor)	{channel="knx:device:bridge:xxx:chx"}		//"Tor unten [MAP(de.map):%s]"
String Tor_Garage				"Garagentor [MAP(de.map):%s]"		<garagedoor>	(Garage)

Rule

Code: Alles auswählen

rule Garagentor
when
	Item Tor_Garage_o changed or
	Item Tor_Garage_u changed or
	System started
then
	if (Tor_Garage_o.state == CLOSED && Tor_Garage_u.state == OPEN) {
		Tor_Garage.postUpdate("OPEN")
	} else if (Tor_Garage_o.state == OPEN && Tor_Garage_u.state == CLOSED) {
		Tor_Garage.postUpdate("CLOSED")
	} else {
		Tor_Garage.postUpdate("MOVE")
	}
end

Transformation

Code: Alles auswählen

CLOSED=geschlossen
OPEN=geöffnet
MOVE=in Bewegung
NULL=undefiniert

[Bubbleman]

Vielen Dank für die Hinweise. Das war sehr hilfreich.

Ich muss hier jetzt aber mal folgendes fragen:
Ihr postet immer die textuellen Definitionen der Items und Things usw.
Ich definieren meinen Kram aber immer per GUI. Kann ich die textuelle Definitionen trotzdem irgendwo einsehen?

Gruß
Thomas

[int5749]

Ich definieren meinen Kram aber immer per GUI. Kann ich die textuelle Definitionen trotzdem irgendwo einsehen?

Hallo Thomas.

Klassisches Jain

Was über die MainUI erstellt wird, landet in einer großen DB und kann dort gelesen werden, ist aber - wenn ich die richtig verstanden habe - nicht wirklich lesbar, bzw. JSON

Ich mache auch in OH3 ALLES per files, ist für mich übersichtlicher

VG Jörg

[udo1toni]

Grundsätzlich kannst Du fast alles auch über die Main UI erstellen. Einschränkungen:
- Mapping über *.map Dateien
- globale Variablen
- Persistence
- exec.whitelist

Es gibt noch einige andere Dinge, die nicht über Main UI konfiguriert werden können, aber das sind dann schon recht spezielle Dinge. Die obige Liste ist aber schon schlimm genug

Du kannst problemlos sowohl Text als auch UI-Konfiguration nutzen. Du solltet natürlich möglichst nicht innerhalb einer "Sorte" Konfiguration mischen, weil das Chaos vorprogrammiert ist (ginge aber ebenfalls).

Hier im Forum ist die textliche Definition im OH1 (bzw. OH2) Stil einfach wesentlich besser lesbar, als die yaml Codeschnipsel, zumal die nur teilweise über die UI direkt auszulesen sind.