UPGRADE IP 9 verfügbar!
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ

NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074

[Gelöst] [V 3.4.5] MQTT mit KNX Subscribe UND Publish

Wissen, Planung & Diskussion zur MQTT Unterstützung im Timberwolf Server.
Stellt uns hier Eure MQTT Projekte und Ideen vor.
Forumsregeln
  • Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
  • Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
  • Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
  • Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln

gbglace
Reactions:
Beiträge: 3585
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1253 Mal
Danksagung erhalten: 1649 Mal

#21

Beitrag von gbglace »

Zelkin hat geschrieben: Mi Aug 31, 2022 8:25 pm Einzig gültige Quelle sind die 3 ko des heizungsaktor..... Um eine Änderung des zustands herbeizuführen muss bei einem Event eine der ko's verändert werden wobei die anderen in dem Moment reagieren
Den Kausalzusammenhang verstehe ich nicht. Warum muss etwas an KO#1, KO#2 passieren wenn man KO#3 per Telegramm verändert bzw. eine Leseanfrage stellt? Warum sollte eine lese-Anfrage und dessen Antwort an einem anderen KNX-KO eine Aktion bewirken? dafür gibt es Flags worüber man regeln kann ob eine Antwort auf einen Readrequest ein KO zu interessieren hat.

Also nur weil Du die Drei KO auslesen lässt um Dir dann in Deiner Logik irgendwie den Zustand zusammenbasteln, warum sollte das eine Reaktion am Aktor in Form von Veränderung der drei KO bewirken?
Grüße
Göran

#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension
Benutzeravatar

Chris M.
Reactions:
Beiträge: 1190
Registriert: Sa Aug 11, 2018 10:52 pm
Wohnort: Oberbayern
Hat sich bedankt: 234 Mal
Danksagung erhalten: 853 Mal
Kontaktdaten:

#22

Beitrag von Chris M. »

Zelkin hat geschrieben: Mi Aug 31, 2022 8:25 pm Also den Wert schreiben (wird durch ein Script in Abhängigkeit der duechschnittstemp der letzten Woche erledigt) und davon ausgehen dass der Wert immer passt...... Würde hier grundsätzlich sogar gehen!
Ja, richtig.

Was anderes ist es, wenn Du der Kommunikation nicht traust, z.B. weil die Verbindung wacklig ist. Dann musst Du regelmäßig den Eigentümer des Zustands abfragen (ein Event) und damit den redundanten Wert aktuell halten - denn sonst "ist die Gefahr hoch, dass sich diese widersprechen. Das muss zwingend vermieden werden!"
Zelkin hat geschrieben: Mi Aug 31, 2022 8:25 pm Dann gehen wir einen Schritt weiter, Betriebsmodi
Das Event ist z. B. Haus ist verlassen (Knopf an der tür oder aus der visu am Handy weil man den Knopf vergessen hat oder durch Erkennung dass die Handys aus dem Haus sind)

Nun ist standby zu beschreiben mit true damit wechseln die beiden anderen auf false..... Event ist klar zustand ist dann standby
Um diesen auslesen zu können muss ich aber alle 3 abfragen da der visu NUR die true schaltungen bekannt sind (iss ja nur publish) steht mir diese info nicht zur Verfügung
Sehr schönes Beispiel!

Stell Dir vor jede betroffene Stelle muss nun selber auf die Event hören ob nun jemand das Haus verlässt oder wieder kommt. Sollte auch nur eine Stelle davon aus irgend welchen Gründen eines dieser Telegramme nicht mitbekommen hast Du plötzlich einen inkonsistenten Zustand zwischen diesen Systemen :shock:

Die Lösung kann daher nur eine (zentrale) Logik sein, die diese Events auswertet und daraus den allgemein gültigen Zustand "Betriebsmodus" bildet. Diesen Betriebsmodus haben alle anderen Geräte nun zu verwenden.

Diese Logik kann übrigens gar nichts "abfragen", die kann nur live mitrechnen wenn das Event "Knopf an der Tür" passiert.
Andernfalls würdest Du halt viele "Klein-Logiken" brauchen die dieses Event auswerten und der "großen Logik" mitteilen was hier als letztes (= ein Zustand) gesendet wurde. Aber welchen Unterschied machen viele kleine zu einer großen Logik?
Ich finde da einen ordentlich programmierten Zustandsautomaten die elegantere und saubere Lösung.

Du wirst aber natürlich über Probleme stolpern für die es keinen "natürlichen" Eigentümer dieses Zustands gibt (wie z.B. dem Binär-Eingang zum Thema offener Türe). Bei mir ist so ein Fall die Information "Erzwinge Wochenende". Da habe ich mir nicht die Mühe gemacht eine Kalender-Einbindung zu bauen (das wäre eine elegante Möglichkeit dafür um Feiertage und Urlaubstage zu kennen), sondern ich habe einen Visu-Button der einfach "Erzwinge Wochenende" ein- bzw. ausschaltet (ändert z.B. wann in der Früh im Schlafzimmer der Rollladen hoch fährt). Da brauche ich nun einen Eigentümer dieses Status. Und dieser Eigentümer ist dann halt die Logik-Engine selbst. Die muss dann aber auch dafür sorgen, dass diese Info immer zur Verfügung steht - auch nach einem Stromausfall.
=> Genau deshalb hatte ich damals für das Wiregate das StateSave-Plugin geschrieben: https://knx-user-forum.de/forum/öffentl ... #post16344

Inzwischen nutze ich Node-RED dafür, was bei mir dann so aussieht:
Bild
(Die drei KNX Blöcke sind für Schreiben bzw. Lesen und dann Antworten; noch besser wären getrennte GAs für Schreiben und Rückmelden, darauf konnte ich im konkreten Fall aber verzichten)
Zelkin hat geschrieben: Mi Aug 31, 2022 8:25 pm Einzig gültige Quelle sind die 3 ko des heizungsaktor..... Um eine Änderung des zustands herbeizuführen muss bei einem Event eine der ko's verändert werden wobei die anderen in dem Moment reagieren
Nö. Das Heizungsaktor-KO zeigt nur den Zustand genau dieses Heizungsaktors an.
Du kannst natürlich eine "Zentral alles abwesend" GA einführen, auf die jeder Heizungsaktor noch hört (hörende GA ist ja jede weitere GA nach der ersten auf einem KO). Aber dann hast Du immer noch 3 Zustände und nicht nur einen.
Und wie soll die Visu-Seite dafür aussehen? "Status: unbekannt, da 2 sagen nicht anwesend, aber 1 sagt doch anwesend"?!

Um nun diesen einen Master zu bekommen kannst Du eine Logik nutzen und basierend auf diesem Status dann die einzelnen Heizungsaktoren schalten. Oder einen Heizungsaktor als Master der Anwesenheit definieren und alle anderen dürfen nur noch darauf hören und niemals schreiben.
Und da man auch das Thema Stromausfall und Wiederstart danach berücksichtigen sollte würde ich persönlich zur Logik mit einem Stromausfall gesicherten Wert setzen und nicht auf die einzelnen Aktoren. Die wissen in der Regel den Status danach nicht mehr. (Oder schreiben ihr Flash kaput, wenn die jeden Statuswechsel dort abspeichern müssen)
Zelkin hat geschrieben: Mi Aug 31, 2022 8:25 pm Die Probleme zu identifizieren und Alternativen zu suchen um Kompatibilität herzustellen ist doch sinnvoller als zu sagen nimm was anderes.
Nur Systeme die die notwendige Funktion bereitstellen können die notwendige Funktion bereitstellen. Die anderen eben nicht. Egal wie lange Du suchst.

Von den Systemen, die die Funktion bereitstellen, kannst Du dann frei nach Lust und Laune aussuchen. Mir ist Deine Wahl dabei ziemlich egal, die muss ja für Dich passen und nicht für mich.
Es gibt einige hier im Forum die sehr gut mit den TWS Logiken können, die wiederum für mich persönlich nicht passen. Das ist aber auch vollkommen egal, weder haben die anderen noch habe ich allgemeingültig recht. Jedem das, was für ihn am besten funktioniert.
CometVisu Entwickler - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

CometVisu Fragen, Bugs, ... bitte im Entwicklungs-Forum, hier nur spezifisches für CV<->Timberwolf.

TWS 2500 ID: 76 + TP-UART - VPN offen, Reboot nur nach Absprache

Ersteller
Zelkin
Reactions:
Beiträge: 38
Registriert: Fr Jan 07, 2022 2:02 pm
Hat sich bedankt: 23 Mal
Danksagung erhalten: 10 Mal

#23

Beitrag von Zelkin »

@gbglace
Das macht der aktor von sich aus!
Der switch automatisch die beiden anderen auf false..... Klar kann ich das lesen raus nehmen um das nicht mitzubekommen, hab dabei aber keine logik oder Sonst was am laufen!

@Chris M.
Melde mich nach dem Schlafen 😆
Zu viel Text auf die nacht

Gutes nächtle an alle die das hier heute noch lesen
Kai
TWS 3500L ID:641 VPN offen, Reboot nach Rücksprache

Ersteller
Zelkin
Reactions:
Beiträge: 38
Registriert: Fr Jan 07, 2022 2:02 pm
Hat sich bedankt: 23 Mal
Danksagung erhalten: 10 Mal

#24

Beitrag von Zelkin »

Hallo zusammen

........... was soll Ich sagen ....... es funktioniert jetzt!

Die Lösung ist noch einfacher als gedacht und macht das was Ich gesucht habe ohne einen extremen Aufwand zu verursachen.

Ohne euch wäre Ich nicht auf den Versuch gekommen, von dem her Vielen Dank :bow-yellow:

Falls also nochmal jemand mit dem Problem zu tun hat:

Man lege für den jeweiligen nicht vorhandenen Status einfach einen weiteren mqtt Topic an
Bsp.: Heizung Sommer Winter:

/30/02/000_30_Z_Haus Heiz So_Wi --> Kxxxx als subscribe um den wert beschreiben zu können
Kxxxx --> /30/02/000_30_Z_Haus Heiz So_Wi Status als Publish um jede änderung mitzubekommen die am anderen KO erfolgt

Der Mehraufwand beschränkt sich also auf die Anlage eines 2. Topic

Somit sind auch die Fehlerquellen mehr oder weniger raus, weil keine logiken oder sonst was dazwischen hängen
KO´s und Ga´s müssen auch keine angelegt werden

Das 2 Topic kann man wie einen normalen Status weiterverwenden, da dieser i.d.R nur als Referenz zum tatsächlichen Schaltvorgang Arbeitet, also sind auch die Logiken / Scripte so wie bei allen anderen Aktoren mit gesondertem Status anwendbar ........ außer Ich hab jetzt noch nen mächtigen Denkfehler drin?!

Habs eben getestet .... kein Loop und Ich kenn den Zustand für die Vis zum Auslesen

Nochmal vielen Dank für die rege diskussion :handgestures-thumbsup:
Kai
TWS 3500L ID:641 VPN offen, Reboot nach Rücksprache

Ersteller
Zelkin
Reactions:
Beiträge: 38
Registriert: Fr Jan 07, 2022 2:02 pm
Hat sich bedankt: 23 Mal
Danksagung erhalten: 10 Mal

#25

Beitrag von Zelkin »

Wie kann Ich das ganze jetzt auf gelöst setzen??
Kai
TWS 3500L ID:641 VPN offen, Reboot nach Rücksprache

gbglace
Reactions:
Beiträge: 3585
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1253 Mal
Danksagung erhalten: 1649 Mal

#26

Beitrag von gbglace »

erledigt.

Naja der KNX hat da selbst schon gewisse Schutzmechanismen gegen loops. im MQTT hast da nun getrennte Objekte wie es ein Aktor halt sonst auch hat, und nun ist es schon OK.
Grüße
Göran

#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension
Antworten

Zurück zu „MQTT“