OH 3.1 kein Musiccast Binding verfügbar? Erst ab 3.3?

[Maxe1983]

Hallo zusammen,

Ich bin noch relativ neu bei OH und aktuell läuft 3.1 als OHabian.

Nun habe ich nach einem Musiccast (Yamaha) Binding gesucht direkt in der OH Oberfläche - ohne Erfolg.

Im Internet bin ich dann auf folgendes Binding gestoßen:
https://next.openhab.org/addons/binding ... musiccast/

Verstehe ich das richtig - das Binding funktioniert erst ab 3.3?

D.h. ich muss mich noch gedulden bis Ende des Jahres ein neues Stable rauskommt?!

Liebe Grüße Maxe

[int5749]

Hi,

es gibt schon seit openHAB 2.x ein Yamaha Musiccast Binding, welches ich auch seit dieser Zeit nutze und auch für openHAB 3.x wurde das Binding erstellt => Musiccast Binding

Der Unterschied: Scheinbar wird nun mit openHAB 3.3.0 das Binding in openHAB Marketplace integriert. Bisher musst Du das Binding noch manuell installieren.

Manuell installieren ist ja relativ einfach: Binding (*.jar) in das entsprechende AddOn Verzeichnis legen und openHAB kümmer sich um die Installation

Fazit: Wenn Du es über die Oberfläche instalieren möchtest, musst Du auf das Release von 3.3.0 warten, wenn Du es bereits jetzt nutzen möchtest, müsstest Du das Binding manuell installieren.

Viele Grüße

[Maxe1983]

Hallo,

Danke dir für die schnelle und sehr ausführliche Antwort.

Dann werde ich mich mal mit der manuellen Binding Installation beschäftigen - habe ich bisher noch nie gemacht.

Danke dir...
Maxe

[udo1toni]

Da ich OH3.3 auf meinem Testsystem habe: Das Addon kommt nicht mehr vom Marketplace, sondern ist nativer Bestandteil von openHAB.

Versionen: Es gibt stable, milestone und snapshot

• Stable: Momentan ist das openHAB3.2.0. Der Code ist fest, es wird keine Änderungen am Code mehr geben, es sei denn, es wird ein sehr schwerwiegender Fehler gefunden, der einfach gefixt werden kann.
• Milestone: Momentan openHAB3.3.0M2. Der Code wird monatlich eingefroren, es gibt keine Fixes, sondern nur einen Wechsel auf den nächsten Milestone.
• Snapshot: Heute (30.03.2022) openHAB3.3.0S2833. Es ist also der 2833ste Build (seit openHAB0!). Builds werden maximal einmal täglich ausgeführt - es sei denn, ein Build wird manuell angestoßen, dann gibt es noch einen Index nach der Build-Nummer (-1, -2 usw.)
  Wird an einem Tag kein Code geändert, so erfolgt auch kein Build. openHAB ist also nicht 2833 Tage alt

Stable ist tausendfach installiert und dementsprechend ist es sehr unwahrscheinlich, dass nach Monaten noch unentdeckte Fehler lauern. Allerdings ist unentdeckt hier das betonte Wort. Wie oben erwähnt: wenn ein Fehler nicht wirklich schwerwiegend ist, bleibt er drin! Alle entdeckten Fehler werden sobald ein Fix verfügbar ist, im folgenden Snapshot gefixt.
Milestone enthält alle Fixes, die zum Zeitpunkt des Freeze bereits gefixt waren. Es kommt gelegentlich vor, dass durch neue Features auch neue Fehler hinzukommen. Und natürlich kann auch ein Fix neue Fehler ins System bringen. Dennoch ist in dieser Version tendenziell weniger kaputt als in Stable!
Snapshot ist tagesaktuell und enthält dementsprechend eventuell auch unentdeckte Fehler.

Unterm Strich kann ich nur empfehlen, Milestone zu installieren.

Übrigens ist niemand gezwungen, openHAB ständig mit upzudaten. Man kann sogar explizit eine bestimmte Version pinnen (das ist eine Funktion von apt), womit selbst bei einem vollständigen Systemupgrade die installierte Version erhalten bleibt.
Gewöhnlich führt ein

Code: Alles auswählen

sudo apt update && sudo apt -y full-upgrade

dazu, dass openHAB auf die letzte Version der ausgewählten Geschmacksrichtung upgedatet wird (also aktuelles Stable, Milestone oder Snapshot).

[int5749]

Da ich OH3.3 auf meinem Testsystem habe: Das Addon kommt nicht mehr vom Marketplace, sondern ist nativer Bestandteil von openHAB.

My bad, da hatte ich noch Widget etc im Kopf und hatte bei Bindings auch den Marketplace der Community gesehen. Aber Du hast natürlich wie so häufig 100% recht. Ich nutze dies schon so lange, das ich gar nicht mitbekommen hatte, dass dies Binding nun integriert wurde
Habe direkt mal mein manuell installiertes Binding (war noch eine 3.1.0 Version) gelöscht und aus dem Repository installiert. Manuell installiert wird eben auch nicht automatisch upgedated

Dann werde ich mich mal mit der manuellen Binding Installation beschäftigen - habe ich bisher noch nie gemacht.

Oder Du installierst die von Udo bereits empfohlene MS-Version, auf der ich (siehe Signatur) ebenfalls bin. Ich nutze die 3.3.x-MS Version seit MS1 und bisher keine Ausfälle in meiner (überschaubaren) Installation festgestellt.

Jedoch habe ich auch nur 1170 Items (davon einige auch nur für Tests/Spielereien), 70 Rules und 21 Bindings aus dem Repository und nun nur noch 1 manuell installiertes Binding (Landroid Worx Mähroboter)

Viele Grüße

[Maxe1983]

Guten Abend zusammen,

Danke vielmals für eure Infos und Ratschläge.

Ich werde mich die Tage mal an einen Update auf 3.3.0M2 ranmachen. Werde aber vorher noch kurz ein Backup von der SD-Karte ziehen - man weiss ja nie

Ich verwende OH bislang nur als Bedienoberfläche für mein KNX und will nun die ersten Dinge zusätzlich mit einbinden.

Hab bis jetzt 1 Binding und 0 Rules

Liebe Grüße Maxe

[Maxe1983]

Hallo Udo und int,

ich bin seit heute stolzer Besitzer vom OH 3.3M3 und das Musiccast Binding wurde auch schon erfolgreich eingebunden.

Der erste Versuch die Musiccast per Item ein- und auszuschalten hat auch schon geklappt.

Nun bin ich an einem Punkt angekommen, den ich noch nie angegangen sind. Ich fasse nochmal ganz kurz meinen aktuellen Stand zusammen...
Bislang verwende ich OH nur als Bedien- und Anzeigenoberfläche für ein KNX. Bin voll und ganz zufrieden.

Nun kommt mein zweites Binding hinzu und meine ersten Fragen...
Wie verknüpfe ich nun mein KNX mit dem Musiccast?
Ich möchte gesteuert über eine GA vom KNX die Musiccast ein- bzw ausschalten.

Wie stelle ich diese Verbindung her?
Wird sowas über eine Rule typischerweise umgesetzt?!
Oder wie ist der Weg zwei unterschiedliche Bindings mit einander zu "verbinden"?

Liebe Grüße und Danke für eure tolle Unterstützung
Maxe

[Maxe1983]

Hallo nochmal,

ich glaube ich habe die Antwort auf meiner Frage bereits im Forum gefunden - ebenfalls von Udo:
viewtopic.php?p=14039#p14039

Ich habe nun zwei Channels mit einem Item verknüpft.

Channel 1 ist eine Lampe als Switch per KNX.
Channel 2 ist "Betrieb" der Musiccast.

Das ganze habe ich auf das bereits vorhandene Item der Lampe verknüpft.

Und nun wird es komisch...
Über die OH-App geht erfolgreich die Lampe und die Musiccast an.
Wenn ich aber über ein KNX-Bedienteil die Lampe (GA passt) ansteuere, dann bleibt Musiccast aus.
JEDOCH ist in der OH-App die Veränderung der Lampe am switch sichtbar?!

Wo ist mein Fehler?

Liebe Grüße Maxe

[int5749]

Hallo Maxe,

wenn ich also richtig verstanden habe, möchtest Du über einen Schalter (physik) ein Item in OH steuern?
Dies ist so erst einmal zwar nicht der Antrieb für openHAB, denn dort läuft alles auf "logischer" Ebene.

Aber: (wie so häufig gibt es ein aber) es gibt die control-Option für ein Thing, welches dann wieder mit einer GA verknüpft wird. ich nutze dies z.B. um meine Sonnenautomatik über eine Taste auf einem Gira-Sensor (aka Schalter, wobei dies bei KNX häufig falsch verwendet wird, den der Schalter ist der Aktor, der vom/von den Sensor/en die Befehle erhält) zu schalten.

Da Du aus KNX schalten möchtest, benötigst Du ein virtuelles Thing im KNX Binding

Code: Alles auswählen

Bridge knx:ip:bridge "MDT SCN-IP000.02" @ "Hausanschlußraum" [  
	type="TUNNEL",
	ipAddress="192.168.1.2",
	autoReconnectPeriod=60
] {
	Thing device GiraTS2_4f_0_0_55 "Gira TS2 4-fach" @ "Esszimmer" [
		address="0.0.55",
		fetch=false,
		pingInterval=600,
		readInterval=0
     ] {
		Type switch-control	: swc1		"Beschattungsautomatik"			[ ga="0/3/10+<0/4/55" ]
    }
}

Das Ganze benötigt dann natürlich noch ein Item

Code: Alles auswählen

Switch SunProtection			"Sonnenschutzautomatik"			{channel="knx:device:bridge:GiraTS2_4f_0_0_55:swc1"}

Damit wird dann auch der Status synchron gehalten, sprich wenn ich in openHAB (Rule oder manuell in der Sitemap/Main UI) das Item schalte, geht auch die LED am Sensor an und ich kann somit über KNX ein Item in openHAB schalten. Damit dies mit dem Musiccast Item funktioniert müssen nun beide Channels an das Item gebunden werden, dazu habe ich aber leider nichts gefunden, ich würde dies wahrscheinlich über eine entsprechende Rule lösen.

Viele Grüße

[udo1toni]

Das Problem ist hier der Trigger. Wenn der Schalter auf knx-Seite eine "echte" Lampe über knx steuert, dann handelt es sich um einen Channel, der mit dem Aktor gekoppelt ist. Der Schalter wird gar nicht direkt verwendet, nur der Zustand der Lampe wird ausgewertet.

Jetzt ist die erste Frage: Soll das so, oder ist das nur ein Test? Denn es hängt entscheidend davon ab, ob Du einen Taster exklusiv für Musicast verwenden möchtest, oder ob Du mit Einschalten der Beleuchtung einfach Musicast mit einschalten möchtest.

Paralleles Einschalten: Ändere den Trigger der Rule auf changed ab:

Code: Alles auswählen

rule "Musicast schalten"
when
    Item MeineLampe changed
then
    MeinMusicast.sendCommand(newState.toString)
end

Wenn die Lampe eingeschaltet wird, zieht das einen Einschaltbefehl für Musicast nach sich, ebenso in der anderen Richtung. Musicast läuft als Slave. Es ist dabei egal, wie die Lampe geschaltet wird, ob per UI, per Rule, von knx per Taster oder auch per Szene, weil der Status in openHAB immer den Zustand der Lampe widerspiegelt.

Dazu braucht es keine Rule. Du musst lediglich beide Channel mit dem selben Item verlinken. Zusätzlich musst Du im Link vom knx Channel auf das Item als Profile "follow" auswählen. Fortan werden Statusänderungen in knx als Befehl an Musicast weitergeleitet.

Unabhängiges Einschalten über eine Taste, die sonst nichts steuert:
Soll eine Taste in knx etwas innerhalb openHAB steuern, aber nichts auf knx-Seite, so muss der betreffende Channel als switch-control Channel definiert werden.
der Unterschied zwischen switch und switch-control:
Bei switch ist openHAB die Schaltzentrale, sie sendet einen Schaltbefehl an knx, dort wird der Schaltbefehl ausgeführt. knx meldet den neuen Schaltzustand an openHAB zurück.
Bei switch-control ist die Rollenverteilung umgekehrt. openHAB nimmt Schaltbefehle von knx an und sendet den neuen Status an knx zurück. openHAB übernimmt sozusagen die Rolle des Aktors. Natürlich übernimmt openHAB diese Rolle nur stellvertretend gegenüber knx. In Wirklichkeit ist ja Musicast das System, welches den Schaltvorgang tatsächlich ausführt.

Auch hier kann man mit Rule und zwei Items arbeiten:

Code: Alles auswählen

rule "Musicast schalten"
when
    Item MeinKnxSchalter received command
then
    MeinMusicast.sendCommand(receivedCommand)
end

weil der Channel als switch-control definiert wurde, werden ankommende Telegramme nicht als Status Änderung gewertet, sondern als Befehle.

Auch hier braucht es keine Rule Jetzt musst Du lediglich die zwei Channel mit dem selben Item verknüpfen. Da knx ohnehin schon als Befehl ankommt, wird dieser Befehl auch direkt an den Musicast Channel weitergeleitet.

Zu beachten ist noch, dass uneingeschränkt die oberste GA-Regel gilt: Nur die jeweils erste (oder Haupt-) GA ist sendend. Das heißt:

Code: Alles auswählen

Type switch         : ch1 "Lampe" [ ga="1/1/1+<1/1/2" ]
Type switch-control : ch2 "Taste" [ ga="1/1/3+1/1/4" ]

GA 1/1/1 wird verwendet, um die Lampe von openHAB aus ein- und auszuschalten. GA 1/1/2 meldet den aktuellen Zustand der Lampe.
GA 1/1/4 wird verwendet, um den Schaltbefehl vom Taster zu empfangen. GA 1/1/3 wird verwendet, um den Zustand des Channels an knx zu senden (denn es ist die erste angegeben GA) Bei ch1 hält knx den Status im Aktor. Bei ch2 hält openHAB den Status (im verknüpften Item).
erhält ein Item, welches mit einem switch-control Channel verknüpft ist, per postUpdate() einen neuen Status, so wird dieser Status an knx gesendet. Dieses Verhalten ist sehr besonders, aber auch gut begründet.

Gewöhnlich wirkt postUpdate() ausschließlich auf den Status eines Items, während sendCommand() ausschließlich einen Befehl an die verknüpften Channel sendet.