Sonoff (Tasmota) RF Bridge in OH3
Moderatoren: Cyrelian, udo1toni
-
- Beiträge: 125
- Registriert: 8. Dez 2020 19:29
Re: Sonoff (Tasmota) RF Bridge in OH3
Nein, die JSONPATH Transformation musst du erst installieren!!!
-
- Beiträge: 10
- Registriert: 21. Jan 2021 00:08
Re: Sonoff (Tasmota) RF Bridge in OH3
Hallo Stachi, JSONPATH habe ich installiert, leider hat sich nicht viel geändert.
Mit folgendem Code erreiche ich jetzt ein "OPEN" statt "Null":
Der Server läuft, das habe ich mit folgender Eingabe überprüft:
Code: Alles auswählen
systemctl status mosquitto.service
Code: Alles auswählen
UID: mqtt:topic:Broker:RFBridge1
label: RF Bridge 1
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:Broker
channels:
- id: Chanel3
channelTypeUID: mqtt:contact
label: TürTest
description: null
configuration:
stateTopic: tele/RFBridge1/RESULT
transformationPattern: JSONPATH:$.RfReceived.RfKey2
on: 7A78B9
OH3 auf einem Raspi3, 6x Sonoff Touch, 3x Sonoff 4Channel pro, 5x Sonoff TH16, 2x Sonoff Pow, 2x Sonoff D1, 8x Sonoff DW1, 2x Sonoff RfBridge, 3x Sonoff PIR, und viele Sonoff Basics, alles mit Tasmota und einiges davon funktioniert sogar mit OH3! In Planung: Einbindung der IP Cams, Wolf Therme, Nukis und Alarmanlage
-
- Beiträge: 125
- Registriert: 8. Dez 2020 19:29
Re: Sonoff (Tasmota) RF Bridge in OH3
Ich hab selbst keine Bridge [emoji28]
Aber wenn du schonmal ein OPEN statt NULL siehst, dann scheint es ja schonmal zu funktionieren.
Wenn beim öffnen deines Kontaktes dann ein CLOSED gesendet wird, dann funktioniert es ja schonmal.
Dann musst du nur noch die Zuweisung der Zustände im Channel drehen [emoji6]
Aber wenn du schonmal ein OPEN statt NULL siehst, dann scheint es ja schonmal zu funktionieren.
Wenn beim öffnen deines Kontaktes dann ein CLOSED gesendet wird, dann funktioniert es ja schonmal.
Dann musst du nur noch die Zuweisung der Zustände im Channel drehen [emoji6]
-
- Beiträge: 10
- Registriert: 21. Jan 2021 00:08
Re: Sonoff (Tasmota) RF Bridge in OH3
So, ich habe ein kleines Erfolgserlebnis, ich habe jetzt einen Channel für die Bridge angelegt und versucht die einzelnen Sensoren dann als Points anzulegen, im ganzen sieht das so aus:
Leider wird mir jetzt dieser ganze Text angezeigt:
Egal welchen Sensor ich nutze kommt bei dem Point immer die ganze Meldung, jedoch mit den unterschiedlichen RfKeys.
Ich hoffe ich bin jetzt endlich auf dem richtigen Weg. Weiss zufällig jemand wie ich es hinbekomme, dass pro Point nur der jeweilig gewünschte RfKey angezeigt wird, vor allem auch nur open oder close.
Vielen Dank für eure Hilfe
Code: Alles auswählen
UID: mqtt:topic:Broker:RFBridge1
label: RF Bridge 1
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:Broker
channels:
- id: Sensoren
channelTypeUID: mqtt:string
label: Sensoren
description: ""
configuration:
stateTopic: tele/RFBridge1/RESULT
Code: Alles auswählen
{"Time":"2021-02-01T17:38:26","RfReceived":{"Sync":8390,"Low":290,"High":840,"Data":"7AA0A6","RfKey":3}}
Ich hoffe ich bin jetzt endlich auf dem richtigen Weg. Weiss zufällig jemand wie ich es hinbekomme, dass pro Point nur der jeweilig gewünschte RfKey angezeigt wird, vor allem auch nur open oder close.
Vielen Dank für eure Hilfe
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
OH3 auf einem Raspi3, 6x Sonoff Touch, 3x Sonoff 4Channel pro, 5x Sonoff TH16, 2x Sonoff Pow, 2x Sonoff D1, 8x Sonoff DW1, 2x Sonoff RfBridge, 3x Sonoff PIR, und viele Sonoff Basics, alles mit Tasmota und einiges davon funktioniert sogar mit OH3! In Planung: Einbindung der IP Cams, Wolf Therme, Nukis und Alarmanlage
-
- Beiträge: 67
- Registriert: 29. Apr 2020 19:15
Re: Sonoff (Tasmota) RF Bridge in OH3
---------------------------
transformationPattern="JSONPATH:$.ENERGY.Power"
---------------------------
exrtahiert zb. bei mir POWER aus dem JOSENPATH
transformationPattern="JSONPATH:$.ENERGY.Power"
---------------------------
exrtahiert zb. bei mir POWER aus dem JOSENPATH
Code: Alles auswählen
Thing topic SoPa1 "So_Panale_1" {
Channels:
Type number : Leistung_1 "Watt_1" [ stateTopic="tele/SolarPanel_1/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Power" ]
Type number : Leistung_2 "Watt_2" [ stateTopic="tele/SolarPanel_2/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Power" ]
Type number : Leistung_3 "Watt_3" [ stateTopic="tele/SolarPanel_3/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Power" ]
}
-
- Beiträge: 10
- Registriert: 21. Jan 2021 00:08
Re: Sonoff (Tasmota) RF Bridge in OH3
Hallo Steinadler,steinadler hat geschrieben: ↑2. Feb 2021 19:09 ---------------------------
transformationPattern="JSONPATH:$.ENERGY.Power"
---------------------------
exrtahiert zb. bei mir POWER aus dem JOSENPATH
Code: Alles auswählen
Thing topic SoPa1 "So_Panale_1" { Channels: Type number : Leistung_1 "Watt_1" [ stateTopic="tele/SolarPanel_1/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Power" ] Type number : Leistung_2 "Watt_2" [ stateTopic="tele/SolarPanel_2/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Power" ] Type number : Leistung_3 "Watt_3" [ stateTopic="tele/SolarPanel_3/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Power" ] }
vielen Dank, das funktioniert bei meinem TH 16 mit der Temperatur und der Luftfeuchtigkeit wunderbar (außer das ich nur die Zahlen ohne Maßeinheiten sehe), aber bei der Bridge klappt es leider nicht, dort bekomme ich immer nur die Ausgabe, die ich schon gepostet habe.
Vielleicht findet sich ja noch ein Forenmitglied mit einer RF Bridge unter OH3 und postet seine Einstellungen.
OH3 auf einem Raspi3, 6x Sonoff Touch, 3x Sonoff 4Channel pro, 5x Sonoff TH16, 2x Sonoff Pow, 2x Sonoff D1, 8x Sonoff DW1, 2x Sonoff RfBridge, 3x Sonoff PIR, und viele Sonoff Basics, alles mit Tasmota und einiges davon funktioniert sogar mit OH3! In Planung: Einbindung der IP Cams, Wolf Therme, Nukis und Alarmanlage
-
- Beiträge: 67
- Registriert: 29. Apr 2020 19:15
Re: Sonoff (Tasmota) RF Bridge in OH3
hi
mal so ne doofe frage(bin halt nur bauer)
-kann dein sensor zwischen auf und zu unterscheiden(2 unterschiedliche keys)?
-wenn ja, dann habe ich die keys von "data" ausgelesen
-also
ich habe die bridge nicht "einprogrammiert-der bridge keine keys zugeordnet"
sondern lese über einer rule(dank toni) die daten aus
warum das bei OH3 nicht gehen soll, kann ich mir nicht vorstellen(ich bau z.z. noch um, auf OH3)
rules
hier geht es nicht um den inhalt(timer usw.), sondern über die auswahl von case
wie du siehst, macht mein sensor 2 unterschiedliche keys(macht eigentich3, der 3.-sabotagekey -lassen wir a ber mal weg)
case "07206E"
case "072067"
einmal für auf, und einaml für zu
danach setze ich die kommandos ab, was du auch immer willst
desweiteren habe ich einfache schalter angelegt, deren zustand vom ereigniss der rule abhängig ist(auf oder zu)
so sieht ein teil meiner items aus
also, wenn du der mqtt werte auslesen kannst, könntest du meiner meinung nach eine auswertung mit der rule machen, die dann wiederum einen schalter bediet
--hat alles auch nachteile, denke es gibt auch bessere lösungen, aber so funktioniert es bei mir
und wenn du die werte von der rule anderst auswerten willst(an, aus--off, on, oder sonst etwas)müsstest du die werte in einer presence.map umwandeln
--da ich nur anfänger bin, verzeiht mir bitte die schlechte programmierung
hoffe, du kommst mit irgendeinem teil von dem geschriebenen, weiter
--nur nicht aufgeben--
mal so ne doofe frage(bin halt nur bauer)
-kann dein sensor zwischen auf und zu unterscheiden(2 unterschiedliche keys)?
-wenn ja, dann habe ich die keys von "data" ausgelesen
-also
ich habe die bridge nicht "einprogrammiert-der bridge keine keys zugeordnet"
sondern lese über einer rule(dank toni) die daten aus
warum das bei OH3 nicht gehen soll, kann ich mir nicht vorstellen(ich bau z.z. noch um, auf OH3)
rules
Code: Alles auswählen
var Timer tZeit = null // Objekt für Timer anlegen
rule "sonoffRF Kontakt Auswahl" // Ruletitel dürfen Leerzeichen und Sonderzeichen enthalten
when
Item RfData01 received update // falls 2 mal der gleiche Befehl kommt
then
if (RfData01.state == NULL) {
logInfo("RfBridge.rules", "Item is null, cancelling...")
return;
}
val sonoffRfData = RfData01.state.toString
logInfo("rfbridge.rules", "Received IT Codes: {}", sonoffRfData)
switch(sonoffRfData) {
case "07206E" : {
So_Ra.sendCommand(ON)
Thread::sleep(500)
playSound("doorbell.mp3", new PercentType(100))
Flur_Licht.sendCommand(ON)
tuerstrasse.sendCommand(ON)
if (Alarmanlage.state == ON)
{
executeCommandLine ("wget https://api.callmebot.com/whatsapp.php?phone=+xxxxxxx&text=Haustür+auf&apikey=xxxxxx")
}
}
case "072067" : { // flurlicht verzögert aus
So_Ra.sendCommand(OFF)
tuerstrasse.sendCommand(OFF)
tZeit?.cancel // falls ein Timer läuft, abbrechen
tZeit = createTimer(now.plusSeconds(30), [ | // Timer anlegen
Flur_Licht.sendCommand(OFF)
])
}
wie du siehst, macht mein sensor 2 unterschiedliche keys(macht eigentich3, der 3.-sabotagekey -lassen wir a ber mal weg)
case "07206E"
case "072067"
einmal für auf, und einaml für zu
danach setze ich die kommandos ab, was du auch immer willst
desweiteren habe ich einfache schalter angelegt, deren zustand vom ereigniss der rule abhängig ist(auf oder zu)
so sieht ein teil meiner items aus
Code: Alles auswählen
//Sensoren
Switch stubenfenster "Stubenfenster" <window> (gSE)
Switch terassentuer "Tür Terasse" <door> (gSE)
Switch tuerstrasse "Haustür" <frontdoor> (gSE)
Switch tuerkeller "Kellertür" <door> (gSE)
Switch tuerbar "Bartür" <door> (gSE)
Switch fensterbar "Fenster Bar" <window> (gSE)
Switch garagentor "Garagentor" <garagedoor> (gSE)
Switch badfensterOben2 "Badfenster ObGe 2" <window> (gSE)
Switch badfensterOben1 "Badfenster ObGe 1" <window> (gSE)
Switch yyFenster "xxx Dachfenster" <window> (gSE, OG_Kinderzimmer2)
Switch yyTerTuer "xxx TerassenTür" <window> (gSE, OG_Kinderzimmer2)
Switch yyTerTuer "xxx TerassenTür" <window> (gSE, OG_Kinderzimmer1)
--hat alles auch nachteile, denke es gibt auch bessere lösungen, aber so funktioniert es bei mir
und wenn du die werte von der rule anderst auswerten willst(an, aus--off, on, oder sonst etwas)müsstest du die werte in einer presence.map umwandeln
--da ich nur anfänger bin, verzeiht mir bitte die schlechte programmierung
hoffe, du kommst mit irgendeinem teil von dem geschriebenen, weiter
--nur nicht aufgeben--
-
- Beiträge: 10
- Registriert: 21. Jan 2021 00:08
Re: Sonoff (Tasmota) RF Bridge in OH3
Hallo Steinadler,
ich habe das Thema von Toni verfolgt, danke erstmal für deine Tipps.
Meine Sensoren haben leider nur einen Befehl, in Zukunft kommen da aber neue. Das mit den Rules werde ich mir Mal ansehen, so weit bin ich noch nicht. Jeder Sensor sendet ja einen eigenen Data "Code", zumindest für das einschalten des Lichts mit Timer sollte das ja ausreichen wenn ich dich richtig verstehe.
Stammen deine Beispiele aus OH3 oder einer älteren Version?
Weisst du zufällig ob ich bei OH3 den Code von dir eingeben kann? (Abgeändert natürlich)
Gruß
ich habe das Thema von Toni verfolgt, danke erstmal für deine Tipps.
Meine Sensoren haben leider nur einen Befehl, in Zukunft kommen da aber neue. Das mit den Rules werde ich mir Mal ansehen, so weit bin ich noch nicht. Jeder Sensor sendet ja einen eigenen Data "Code", zumindest für das einschalten des Lichts mit Timer sollte das ja ausreichen wenn ich dich richtig verstehe.
Stammen deine Beispiele aus OH3 oder einer älteren Version?
Weisst du zufällig ob ich bei OH3 den Code von dir eingeben kann? (Abgeändert natürlich)
Gruß
OH3 auf einem Raspi3, 6x Sonoff Touch, 3x Sonoff 4Channel pro, 5x Sonoff TH16, 2x Sonoff Pow, 2x Sonoff D1, 8x Sonoff DW1, 2x Sonoff RfBridge, 3x Sonoff PIR, und viele Sonoff Basics, alles mit Tasmota und einiges davon funktioniert sogar mit OH3! In Planung: Einbindung der IP Cams, Wolf Therme, Nukis und Alarmanlage
- udo1toni
- Beiträge: 14415
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Sonoff (Tasmota) RF Bridge in OH3
Es geht doch um Kontakte, wenn ich es richtig in Erinnerung habe...
Dies hier:
kommt, wenn ein Kontakt betätigt wird? Wurde der Kontakt geschlossen oder geöffnet? Und wie sieht es aus, wenn der selbe Kontakt in der anderen Richtung betätigt wird?
Oder handelt es sich nur um einen Moment-Kontakt (also einen Taster, der kurz gedrückt wird)?
Wenn wir das JSON etwas aufhübschen, sieht es so aus:
und man kann Nun gut die Struktur erkennen. Es gibt zwei interessante Werte, nämlich RfKey und Data. Ich könnte mir vorstellen, dass Data je nach Zustand des Kontakts unterschiedliche Daten enthält. Sollte das nicht der Fall sein, so ist es m.E. nicht möglich, den Zustand des Kontakts zu ermitteln.
Um RfKey auszulesen, braucht es eine jsonpath Transformation, die sieht so aus: JSONPATH:$.RfReceived.RfKey und liefert die Zahl 3. Voraussetzung ist natürlich, dass der jsonpath Transformation Service installiert ist
Da aber vielleicht Data auch eine Rolle spielen könnte, ist es eventuell besser, die Transformation erst in einer Rule vorzunehmen. Das heißt, Du verlinkst den Result Channel mit einem String Item. Dann kommt eine Rule zum Zug, welche bei Änderung triggert. In der Rule wertest Du RfKey und evtl. Data aus. Über RfKey entscheidest Du, welches Item die Rule manipulieren soll, über Data (falls unterschiedlich) welchen Zustand das Item bekommen soll. Entfällt Data, so kannst Du allenfalls das jeweilige Item toggeln lassen.
Es wäre also zunächst hilfreich, einen kompletten Satz aller möglichen JSON Objekte zu haben, mehrfach hintereinander einen Kontakt öffnen/schließen, dies jeweils für jeden Kontakt, anschließend alle JSON Objekte in eine Liste eintragen und die Unterschiede anschauen.
Time ist immer unterscheidlich (logisch...), Sync, Low und High werden - wenn überhaupt - nur intern von Bedeutung sein, aber Data und RfKey sollten genau untersucht werden...
Dies hier:
Code: Alles auswählen
{"Time":"2021-02-01T17:38:26","RfReceived":{"Sync":8390,"Low":290,"High":840,"Data":"7AA0A6","RfKey":3}}
Oder handelt es sich nur um einen Moment-Kontakt (also einen Taster, der kurz gedrückt wird)?
Wenn wir das JSON etwas aufhübschen, sieht es so aus:
Code: Alles auswählen
{
"Time": "2021-02-01T17:38:26",
"RfReceived": {
"Sync": 8390,
"Low": 290,
"High": 840,
"Data": "7AA0A6",
"RfKey": 3
}
}
Um RfKey auszulesen, braucht es eine jsonpath Transformation, die sieht so aus: JSONPATH:$.RfReceived.RfKey und liefert die Zahl 3. Voraussetzung ist natürlich, dass der jsonpath Transformation Service installiert ist
Da aber vielleicht Data auch eine Rolle spielen könnte, ist es eventuell besser, die Transformation erst in einer Rule vorzunehmen. Das heißt, Du verlinkst den Result Channel mit einem String Item. Dann kommt eine Rule zum Zug, welche bei Änderung triggert. In der Rule wertest Du RfKey und evtl. Data aus. Über RfKey entscheidest Du, welches Item die Rule manipulieren soll, über Data (falls unterschiedlich) welchen Zustand das Item bekommen soll. Entfällt Data, so kannst Du allenfalls das jeweilige Item toggeln lassen.
Es wäre also zunächst hilfreich, einen kompletten Satz aller möglichen JSON Objekte zu haben, mehrfach hintereinander einen Kontakt öffnen/schließen, dies jeweils für jeden Kontakt, anschließend alle JSON Objekte in eine Liste eintragen und die Unterschiede anschauen.
Time ist immer unterscheidlich (logisch...), Sync, Low und High werden - wenn überhaupt - nur intern von Bedeutung sein, aber Data und RfKey sollten genau untersucht werden...
openHAB4.2.0 stable in einem Debian-Container (bookworm) (Proxmox 8.2.4, LXC), mit openHABian eingerichtet