Hallo,
nachdem ich mit meiner FHEM Installation auf einen neue VM umgezogen bin läuft nun fast alles wieder. Nur mein Smarthomedisplay https://forum.fhem.de/index.php/topic,68948.0/topicseen.htmlzeigt mir den Status der Fenster etc. nicht mehr an.
Der Fehler ist wohl dass die MQTT-Bridge Geräte nicht angelegt werden können. Als MQTT Server verwende ich das interne Modul MQTT2_SERVER.
Wenn ich die MQTT_Bridge Geräte anlegen möchte define MQTT_LED_Bad_Heizung_EG MQTT_BRIDGE AL_HZ_Bad_EG bekomme ich folgenden Fehler:
client device hash no IODev provided
Die Logdatei sagt mir auch nicht mehr:
2021.07.09 10:51:02.183 3: No I/O device found for MQTT_LED_Bad_Heizung_EG
2021.07.09 10:51:02.183 1: client device hash no IODev provided
2021.07.09 10:51:02.183 1: define MQTT_LED_Bad_Heizung_EG MQTT_BRIDGE AL_HZ_Bad_EG: client device hash no IODev provided
Wo wird denn das fehlende IODev definiert? Was fehlt mir hier noch?
Gruß Jochen
Zitat von: Jochen1977 am 09 Juli 2021, 11:10:46
Der Fehler ist wohl dass die MQTT-Bridge Geräte nicht angelegt werden können. Als MQTT Server verwende ich das interne Modul MQTT2_SERVER.
Das Modul MQTT_BRIDGE ist nicht dafür ausgelegt, (direkt) mit dem MQTT2_SERVER zusammen zu arbeiten.
Man kann da zwar einen Würgaround basteln*, ich würde aber für diesen Anwendungsfall dazu raten, entweder die Daten durch einen Event-Handler (z.B. notify) direkt an die Display-Topics zu publishen ("set M2Server publish <topic> >payload>"), oder statt dem (deprecated!) MQTT_BRIDGE MQTT_GENERIC_BRIDGE einzusetzen; das kann auch mit MQTT2_SERVER verwendet werden, ohne dass man irgendwelchen externen libs braucht.
*Würgaround wäre: 00_MQTT.pm auf den M2S lauschen lassen. Vermutlich hattest du das auch so, aber dieses Modul kann nicht geladen werden, weil mind. eine Perl-lib fehlt (siehe Wiki). Es müßte beim FHEM-Start dazu auch was im Log stehen.
Hm,
geht das auch direkt. Ich habe ein notify welches mir den Status meiner Sensoren in einen Zahlenwert wandelt. Dieser wird dann in einen Dummy geschrieben. Der Dummywert wird dann mittels der Bridge für das Display zur Verfügung gestellt. Vorgegangen bin ich nach dieser Anleitung hier:
https://www.bernd-schubart.de/homestatusdisplay-smart-home-status-immer-im-blick/
Mit dem Unterschied den internen MQTT Server und nicht extern Mosquitto einzusetzen.
Die Anleitung hatte ich auch kurz angesehen, aber da wird - soweit ich das erkennen kann - nur jedes FHEM-Device (nach heutiger Lesart: unnötigerweise) mit einer MQTT_BRIDGE "gedoppelt", die dann jede Änderung 1:1 an den MQTT-Server schickt. Die Umwandlung in einen Farbwert etc. findet dann auf dem ESP statt.
Zitat von: Jochen1977 am 09 Juli 2021, 12:24:19
[....] Ich habe ein notify welches mir den Status meiner Sensoren in einen Zahlenwert wandelt. Dieser wird dann in einen Dummy geschrieben. Der Dummywert wird dann mittels der Bridge für das Display zur Verfügung gestellt.
Das ist mir zu abstrakt. Ich würde mind. das notify benötigen, um klarer zu sehen. Insgesamt _glaube ich_, dass das - nach heutigen Maßstäben - auch zu kompliziert umgesetzt ist.
Zitatgeht das auch direkt.
Ziemlich sicher. Es gibt - wie vorhin schon angemerkt - m.E. zwei Wege, die man heute gehen kann:
- MQTT_GENERIC_BRIDGE kann alle Readings/Events von den Geräten "abgreifen", die an das Display gehen sollen und dann ggf. auch mit "expression" gleich passend umrechnen;
- die "notify+Sammeldevice-dummy"-Lösung würde man heute vermutlich mit einem notify+MQTT2_DEVICE lösen: das notify setzt Readings am M2D, das dann in der setList die passenden Topics "kennt" und dann den gesetzten Wert direkt publisht.
Ich vermute, dass dir letzteres näher liegt, weil man dann den "Sollstatus" der einzelnen Elemente leichter (an einem Ort zusammengefasst) erkennen kann.
So oder so kann ich gerne versuchen, dich beim Umbau zu unterstützen, aber ich sollte dann RAW-Definitionen vom notify und dem MQTT2_DEVICE haben, das eigentlich heute schon für den ESP vorhanden sein sollte?
(Dazu ggf. ein paar passende Events bzw. Info, um welche Geräte (TYPE) es geht und den dummy).
O.K. das ist ja super.
Dann trage ich mal die Daten zusammen. Es gibt bei mir 3 verschiedene Fälle:
1.) Der Status eines Device wird angezeigt (z.B. einzelnes Fenster)
2.) Mehere Device werden als structure zusammengefasst und dann der Zustand der structure angezeigt (z.B. mehrere Fenster in einem Raum)
3.) Der Zustand eines Device wird mit einem anderen Wert verglichen und dann daraus ein Wert ausgegeben (z.B. Heizung soll/ist -> zu warm...)
Hier der Fall 1 (Fenster):
Device ist ein HM-Sec-RHS oder ein HM-Sec-SC-2. Der Status ist also entweder open oder closed oder tilted
Bisher habe ich diesen Status dann mit einer MQTT-Bridge ausgewertet:
DeviceOverview
MQTT_LED_Fenster_Buero_Jochen ???
Internals
DEF HM_FE_Buero_Jochen
FUUID 5fa13466-f33f-f73d-1dc8-be88dba583c4fec8
FVERSION 10_MQTT_BRIDGE.pm:0.236580/2021-02-01
IODev mqtt
NAME MQTT_LED_Fenster_Buero_Jochen
NOTIFYDEV HM_FE_Buero_Jochen
NR 222
NTFY_ORDER 50-MQTT_LED_Fenster_Buero_Jochen
STATE ???
TYPE MQTT_BRIDGE
publishState fhem/status/window/Buero_Jochen_Fenster
retain *:1
Readings IODev
mqtt 2021-07-09 17:38:54
transmission-state outgoing publish sent 2021-07-05 12:31:10
MQTT_LED_Fenster_Buero_Jochen Attributes IODev mqtt
Probably associated with
HM_FE_Buero_Jochen closed HMCCUDEV
Fall 2:
Hier habe ich z.B. alle Fenster eines Raums zu einer Structure zusammengefasst:
DeviceOverview
A_Fe_Wohnzimmer closed
fensterstructure
CHANGEDCNT 0
DEF
fensterstructure HM_FE_Wohnzimmer1 HM_FE_Wohnzimmer2 HM_FE_Wohnzimmer3
FUUID 6016904b-f33f-f73d-ac0c-487af5c03a2cf3de
FVERSION 98_structure.pm:0.238180/2021-02-24
NAME A_Fe_Wohnzimmer
NOTIFYDEV HM_FE_Wohnzimmer1,global,HM_FE_Wohnzimmer2,HM_FE_Wohnzimmer3
NR 446
NTFY_ORDER 50-A_Fe_Wohnzimmer
STATE closed
TYPE structure
Readings LastDevice
HM_FE_Wohnzimmer3 2021-07-05 13:12:21
LastDevice_Abs HM_FE_Wohnzimmer3 2021-07-05 13:12:21
state closed 2021-07-05 13:12:21
A_Fe_Wohnzimmer
Attributes
genericDeviceType window
homebridgeMapping ContactSensorState=state,values=closed:CONTACT_DETECTED;;open:CONTACT_NOT_DETECTED
room Fenster,Wohnzimmer
userattr fensterstructure fensterstructure_map structexclude
Probably associated with
Fenster_Haus undefined
structure HM_FE_Wohnzimmer1 closed HMCCUDEV
HM_FE_Wohnzimmer2 closed HMCCUDEV
HM_FE_Wohnzimmer3 closed HMCCUDEV
n_Fe_Wohnzimmer active notify
Diesen Wert dann per notify weitergeleitet:
nternals DEF
A_Fe_Wohnzimmer set A_Fe_Wohnzimmer_dummy $EVENT
FUUID 60169496-f33f-f73d-06a5-1c97bf030710c2ac
FVERSION 91_notify.pm:0.241290/2021-04-02
NAME n_Fe_Wohnzimmer
NOTIFYDEV A_Fe_Wohnzimmer
NR 448
NTFY_ORDER 50-n_Fe_Wohnzimmer
REGEXP A_Fe_Wohnzimmer
STATE active
TYPE notify
Readings state active 2021-07-09 17:38:52
An den Dummy für alle Fenster zusammen:
Internals
FUUID 60169225-f33f-f73d-9ec4-c7d7bdac14c6d7cc
FVERSION 98_dummy.pm:0.206650/2019-12-06
NAME A_Fe_Wohnzimmer_dummy
NR 447
STATE closed
TYPE dummy
Readings state closed 2021-07-05 13:12:21
A_Fe_Wohnzimmer_dummy
Attributes
alexaName Fenster Wohnzimmer
alexaProactiveEvents 1
event-on-change-reading state
eventMap undefined:open open:open closed:closed
genericDeviceType contact
homebridgeMapping ContactSensorState=state,values=closed:CONTACT_DETECTED;open:CONTACT_NOT_DETECTED
room Alexa,Wohnzimmer
setList open closed
Dies hat den Vorteil dass der Status auch über Alexa abgefragt werden kann. Per App sehe ich auch die einzelnen Sensoren aber per Sprachsteuerung den Zustand abfragen kann ich nur wenn sie als structure zu einem dummy weitergeleitet werden. (Dies ist aber eine andere Baustelle). Als Zustand brauche ich hier nur closed wenn alle Fenster in dem Raum zu sind oder open wenn mindesten 1 Fenster offen oder gekippt ist. Das ergibt dann grün / rot auf meinem Display.
Fall 3:
Für die Heizungen habe ich mehr Stati. Es ist immer wieder vorgekommen dass ein HM-CC-RT-DN nach der Kalibrierfahrt das Ventil nicht geschlossen hat. Die Heizung hat dann weitergeheizt obwohl die Temperatur erreicht war. Auch wollte ich z.B. wissen ob die Wohlfühltemperatur für das Duschen schon erreicht ist. Deswegen ist hier die Definition etwas länger:
HM_HZ_Bad_EG:4.ACTUAL_TEMPERATURE.* { if (ReadingsVal("HM_FE_Bad_EG","1.STATE","") eq "open") { fhem("set AL_HZ_Bad_EG 0")}
elsif((ReadingsVal("HM_HZ_Bad_EG","4.ACTUAL_TEMPERATURE","") - 2) > (ReadingsVal("HM_HZ_Bad_EG","4.SET_TEMPERATURE","")) and ((ReadingsVal("HM_HZ_Bad_EG","4.ACTUAL_TEMPERATURE","") - 6) < (ReadingsVal("HM_HZ_Bad_EG","4.SET_TEMPERATURE",""))) and (ReadingsVal("HM_HZ_Bad_EG","4.VALVE_STATE","") < 4)) { fhem("set AL_HZ_Bad_EG 6")}
elsif((ReadingsVal("HM_HZ_Bad_EG","4.ACTUAL_TEMPERATURE","") - 2) > (ReadingsVal("HM_HZ_Bad_EG","4.SET_TEMPERATURE","")) and ((ReadingsVal("HM_HZ_Bad_EG","4.ACTUAL_TEMPERATURE","") - 6) > (ReadingsVal("HM_HZ_Bad_EG","4.SET_TEMPERATURE",""))) and (ReadingsVal("HM_HZ_Bad_EG","4.VALVE_STATE","") < 4)) { fhem("set AL_HZ_Bad_EG 7")}
elsif((ReadingsVal("HM_HZ_Bad_EG","4.ACTUAL_TEMPERATURE","") - 2) > (ReadingsVal("HM_HZ_Bad_EG","4.SET_TEMPERATURE","")) and (ReadingsVal("HM_HZ_Bad_EG","4.VALVE_STATE","") > 4)) { fhem("set AL_HZ_Bad_EG 5")}
elsif((ReadingsVal("HM_HZ_Bad_EG","4.ACTUAL_TEMPERATURE","") + 2) < (ReadingsVal("HM_HZ_Bad_EG","4.SET_TEMPERATURE","")) and (ReadingsVal("HM_HZ_Bad_EG","4.VALVE_STATE","") < 4)) { fhem("set AL_HZ_Bad_EG 4")}
elsif((ReadingsVal("HM_HZ_Bad_EG","4.ACTUAL_TEMPERATURE","") + 2) < (ReadingsVal("HM_HZ_Bad_EG","4.SET_TEMPERATURE","")) and (ReadingsVal("HM_HZ_Bad_EG","4.VALVE_STATE","") > 4)) { fhem("set AL_HZ_Bad_EG 3")}
elsif(ReadingsVal("HM_HZ_Bad_EG","4.ACTUAL_TEMPERATURE","") - (ReadingsVal("HM_HZ_Bad_EG","4.SET_TEMPERATURE","")) < 2 and (ReadingsVal("HM_HZ_Bad_EG","4.SET_TEMPERATURE","") - (ReadingsVal("HM_HZ_Bad_EG","4.ACTUAL_TEMPERATURE",""))) < 2 and (ReadingsVal("HM_HZ_Bad_EG","4.VALVE_STATE","") > 4)) { fhem("set AL_HZ_Bad_EG 2")}
elsif(ReadingsVal("HM_HZ_Bad_EG","4.ACTUAL_TEMPERATURE","") - (ReadingsVal("HM_HZ_Bad_EG","4.SET_TEMPERATURE","")) < 2 and (ReadingsVal("HM_HZ_Bad_EG","4.SET_TEMPERATURE","") - (ReadingsVal("HM_HZ_Bad_EG","4.ACTUAL_TEMPERATURE",""))) < 2 and (ReadingsVal("HM_HZ_Bad_EG","4.VALVE_STATE","") < 4)) { fhem("set AL_HZ_Bad_EG 1")} }
Was hier noch fehlt ist zu prüfen ob die Zentralheizung überhaupt eingeschaltet ist. Jetzt im Sommer zeigen die LED zwar den Zustand im Vergleich zum Sollwert an aber das verwirrt. Somit möchte ich hier mittelfristig noch den Wert 1.TEMPERATUR des HM-WDS30-OT2-SM-2 aus dem Heizkeller mit einbauen. Wenn dieser Wert (Vorlauftemperatur) kleiner als 35 Grad ist dann ist die Zentralheizung wohl ausgeschaltet und die LED soll den Wert 0 (dunkel) bekommen. Wenn jetzt eh alles anders wird ist dies wohl der Zeitpunkt das mit einzubauen.
Hier noch der Rest vom notify:
FUUID 603aa93e-f33f-f73d-4a8f-b4e43be5db605357
FVERSION 91_notify.pm:0.241290/2021-04-02
NAME AL_HZ_Bad_EG_notify
NOTIFYDEV HM_HZ_Bad_EG
NR 484
NTFY_ORDER 50-AL_HZ_Bad_EG_notify
REGEXP HM_HZ_Bad_EG:4.ACTUAL_TEMPERATURE.*
STATE active
TYPE notify
Ich hoffe das sind die Angaben die Du hier brauchen kannst. Wenn noch was fehlt schiebe ich das gerne nach.
Danke und Gruß
Jochen
Zitat von: Jochen1977 am 09 Juli 2021, 18:10:18
O.K. das ist ja super.
Dann trage ich mal die Daten zusammen. Es gibt bei mir 3 verschiedene Fälle:
1.) Der Status eines Device wird angezeigt (z.B. einzelnes Fenster)
2.) Mehere Device werden als structure zusammengefasst und dann der Zustand der structure angezeigt (z.B. mehrere Fenster in einem Raum)
3.) Der Zustand eines Device wird mit einem anderen Wert verglichen und dann daraus ein Wert ausgegeben (z.B. Heizung soll/ist -> zu warm...)
OK, dann fangen wir mal mit den Fällen 1&2 an...
Statt vieler MQTT_BRIDGE-Devices verwenden wir _eine_ MQTT_GENERIC_BRIDGE-Instanz:
defmod MGB1 MQTT_GENERIC_BRIDGE mqttDisplay
attr MGB1 IODev <MQTT2_FHEM_Server>
attr MGB1 globalDefaults sub:base=fhem/status/set pub:base=fhem/status retain=1Anmerkungen:
- Wer schon eine MGB im Einsatz hat, kann auch die verwenden, muss sich dann aber ggf. mit dem "Ausrufezeichen" beschäftigen, wenn einzelne Readings (oder alle) an mehrere Topics verteilt werden sollen (@Jochen1977: einfach überlesen!)
- "sub" brauchen wir für das Display eigentlich nicht, aber falls jemand den Sketch mit Tastern ergänzt, ist es evtl. interessant...
- "retain" ist so eine Sache... Hier ist es gewollt, grundsätzlich würde ich davon abraten bzw. das ggf. am einzelnen Device nachrüsten, wenn die MGB auch für andere Zwecke eingesetzt wird. (Da ich das nicht einsetze, bin in nicht sicher, ob die Syntax passt. Bitte selbst prüfen, ob es tut, was es soll...)- <MQTT2_FHEM_Server> ist ein Platzhalter. Da du "00_MQTT.pm" offenbar wieder ans Laufen bekommen hast: MGB kann mit beiden IO-Modul-Typen eingesetzt werden, so dass das vermutlich bei dir "immer" funktioniert, egal, ob du das Attribut setzt oder nicht. Hier würde ich empfehlen, direkt auf den M2-Server zu zeigen, auf den das Display ja subscribed hat, wenn ich das richtig verstanden habe.
Was tut das nun? Erst mal nichts. Die MGB erweitert "nur" die Liste der global verfügbaren Attribute um ein paar, mit denen man (fast) _jedes beliebige FHEM-Gerät_ mit "MQTT-Fähigkeiten" aufrüsten kann...
ZitatHier der Fall 1 (Fenster):
Das sollte dann ohne weiteres mit einem einzigen Attribut "erschlagen" werden können:
attr HM_FE_Buero_Jochen mqttDisplayPublish state:topic={"$base/window/Buero_Jochen_Fenster"}ZitatFall 2:
Wenn "Fall 1" klappt, sollte es kein Problem sein, das auf "Fall 2" zu übertragen - es sollte eine Zeile an der structure (!) reichen.
Zu der hätte ich noch ein paar Anmerkungen:
- "undefined" als state kommt vermutlich nur raus, weil keine client-state-priority gesetzt ist. Schau dir das mal an, ich bin ziemlich sicher, dass das hilft, die eventMap am "dummy" zu vermeiden.
- OB der dummy überhaupt benötigt wird, wäre die 2. Frage. Ich _glaube_, dass nicht. Bzgl. der "STATE"-Korrektur: s.o., und auch, was die Sprachsteuerung angeht, sollte es möglich sein, die passenden Attribute auch direkt an der structure zu setzen. Das ist aber nicht mein "Spezialgebiet"...
Was das notify angeht, schlage ich vor, dass wir uns das ansehen, wenn du die ersten beiden "Fälle" umgestellt hast?
(Wenn das Prinzip dann klar ist und du die Lösung "gut" findest, dann auch gleich für deine anderen Devices, die in diese Kategorien fallen?).
So,
endlich habe ich etwas Zeit gefunden die ganzen device und structures auf das neue Attribut umzustellen. Es funktioniert. Auch Deinen Vorschlag mit der clientstate-priority habe ich umgesezt. Die Abfragegeschichte mit Alexa werde ich in den nächsten Tagen testen. Mal sehen ob das jetzt auch geht.
In den Anmerkungen schreibst Du dass retain in den Devices besser aufgehoben ist. Kannst Du mir das näher erklären?
Die alten mqtt Bridge Devices sind ja in der Config noch drin auch wenn sie nicht angelegt werden da ja was fehlt. Lassen sich die irgenwie aus der config löschen oder sollte ich da "von Hand" eher nichts löschen?
Gruß Jochen
Zitat von: Jochen1977 am 20 Juli 2021, 15:38:24
In den Anmerkungen schreibst Du dass retain in den Devices besser aufgehoben ist. Kannst Du mir das näher erklären?
"retain" sollte man mAn. in der Regel _gar nicht_ setzen: Wir hatten einige wenige Fälle, da sind dann bei reboots Rollläden gefahren usw....
Also ist meine Empfehlung, das - wenn überhaupt, dann eben nur - sehr gezielt da zu setzen, wo man es _wirklich!_ braucht...
Zitat
Die alten mqtt Bridge Devices sind ja in der Config noch drin auch wenn sie nicht angelegt werden da ja was fehlt. Lassen sich die irgenwie aus der config löschen oder sollte ich da "von Hand" eher nichts löschen?
Na ja, entweder es fehlen Perl-Module. Dann wird 00_MQTT nicht geladen, und in der Folge dann auch nicht MQTT_.* (BRIDGE/DEVICE). Dann ist es in der laufenden Config auch nicht zu sehen...
Das war aber anscheinend doch (wieder?) der Fall, daher meine diesbezügliche Bemerkung. Wie dem auch sei: Wenn (!) das mit MGB jetzt funktioniert, kannst (und solltest) du die gefahrlos löschen... (Das würde ich aber in unserem Fall hier nochmal absichern bzw. die Devices gesondert als RAW-List wegspeichern!)