Hallo folgendes Problem hab ich:
Hab ein dummy mit dem ich eine Startzeit einstelle für automatische Bewässerung. Jetzt hab ich das über mosquitto auf meinem anderen Fhem (eigentlich läuft die Hardware auf einem Pi und 2 dahinter liegende Fhem sollen das steuern können) als MQTT2 Device angelegt.
Das lesen der Zeit vom anderen Fhem funktioniert problemlos über readingList.
Internals:
CFGFN
CID Beregnung2start
DEF Beregnung2start
DEVICETOPIC MQTT2_Beregnung2start
FUUID 6050b2f8-f33f-d8e8-0000-91515077060e0e18
IODev mosquitto
LASTInputDev mosquitto
MSGCNT 1
NAME MQTT2_Beregnung2start
NR 3355
STATE 08:00
TYPE MQTT2_DEVICE
mosquitto_MSGCNT 1
mosquitto_TIME 2021-03-17 08:19:35
READINGS:
2021-03-16 14:30:32 associatedWith Test
2021-03-17 08:19:35 state 08:00
Attributes:
IODev mosquitto
readingList SmartHomeOtto/Beregnung2start/state:.* state
room MQTT2_DEVICE
nur wie bekomme ich das auch über das Device gesteuert?
Wenn ich mit setlist state:time das Zeitwählfeld einstellen will dann schreit fhem das das nicht geht...
Es sollte aber über das Zeitwahlfeld z.B. 07:55 auswählbar sein und das ganze dann per setList auf dem anderen Fhem so eingestellt werden. WIe mach ich das?
danke Anton
Habe zwar überhaupt nicht verstanden, was jetzt wie wo warum landet, aber jedenfalls kann ich nicht nachvollziehen, dass MQTT2_DEVICE irgendein Problem damit haben sollte, das time-Widget zu verwenden:
defmod MQTT2_Beregnung2start MQTT2_DEVICE Beregnung2start
attr MQTT2_Beregnung2start IODev m2server
attr MQTT2_Beregnung2start readingList SmartHomeOtto/Beregnung2start/state:.* time
attr MQTT2_Beregnung2start setList time:time tasmota/sonoff/cmnd/Power1 $EVTPART1
attr MQTT2_Beregnung2start setStateList on off
PS: Für MQTT2_DEVICE ist es für Helfer meistens einfacher, wenn du eine RAW-Def lieferst.
Jetzt hab ich nur noch das problem wie ich webCmd definieren soll damit nur die Zeit erscheint.
Definiert ist folgendes:
define MQTT2_Beregnung1start MQTT2_DEVICE Beregnung1start
setuuid MQTT2_Beregnung1start 6051adcb-f33f-d8e8-2bfd-61fdb10c66889e29
attr MQTT2_Beregnung1start IODev mosquitto
attr MQTT2_Beregnung1start readingList SmartHomeOtto/Beregnung1start/state:.* state
attr MQTT2_Beregnung1start room MQTT2_DEVICE
attr MQTT2_Beregnung1start setList time:time SmartHomeOtto/Beregnung1start/state $EVENT
attr MQTT2_Beregnung1start webCmd time
Das funktioniert mit einem Schönheitsfehler: Vor der Zeit steht dann time im Status und zwar so:
MQTT2_Beregnung1start time 04:00 und daneben die Zeit änderbar.
Wie bekomme ich nur die Zeit?
Danke Anton
Zitat von: Beta-User am 18 März 2021, 11:44:41
attr MQTT2_Beregnung2start setStateList on off
hast du übersehen?
Ansonsten wäre es gut, du würdest dir ein paar Grundlagen aneignen, in ungeordneter Reihenfolge:
- MQTT: Vermeidung von unerwünschten loops => Topic in Sende- und Empfangsrichtung haben unterschiedlich zu sein (!)
- Device aufhübschen: stateFormat allg. (da gibt es viele Beispiele, u.a. in der mqtt2-attrTemplate-File; ich vermute, du bekommst den doppelten Text nicht ohne weiteres/einigen Aufwand weg)
- etwas Perl und Regex: Wie entferne ich ggf. unerwünschten Text? (regex101.com).
hab ich nicht übersehen nur ändert setStateList on off nix am Ergebnis - und wenn es keinen Einfluß auf das Ergebnis hat...
Das mit den unterschiedlichen Topic verstehe ich jetzt nicht denn in den Beispielen steht z.B. bei den Tasmota (ich zitiere nur die Zeilen die identisch bei readinglist und setlist sind)
readngList:
DVES_9B01BD:cmnd/DVES_9B01BD/POWER:.* POWER\
setList:
on cmnd/DVES_9B01BD/POWER on\
off cmnd/DVES_9B01BD/POWER off\
also für mich schaut das gleich aus und ist aus dem Wiki Praxisbeispielen.
Meine anderen MQTT2 Devices laufen nach dem gleich Schema nur will ich da nur 2 Zustände umschalten und da kommt keine Loops zustande.
Beim Rest werde ich es schon irgendwie auf die Reihe kriegen - dachte nur es gibt eine einfache Lösung die ich nur nicht sehe..
danke für die Aufklärung anton
Ich lese nur mit, aber das Beispiel von Beta-User aus #1 funktioniert bei mir bez. des Widgets.
Lösche ich attr MQTT2_Beregnung2start setStateList on off - ist das Widget leer
Also die Aussage
Zitathab ich nicht übersehen nur ändert setStateList on off nix am Ergebnis - und wenn es keinen Einfluß auf das Ergebnis hat...
Kann ich nicht nachstellen
Gruß Otto
Danke für den Hinweis auf das Wiki, hab's korrigiert...
(Das hat mal jemand beigesteuert und es stammt aus der Zeit, als ich selbst noch keine Tasmota im Einsatz hatte.)
Also: Unbedingt unterschiedliche Topics!
Sorry aber ich verstehe es trotzdem nicht:
Topic ist soweit mir bekannt der "Pfad" zu dem Gerät bei MQTT das physisch vorhanden ist und z.B. einfach ein Schalter ist der Zustände hat.
Das wird über MQTT quasi anderen Empfängern die auf diese Nachrichten lauschen zur Verfügung gestellt und erlaubt bei einem Schalter auch den von Empfängerseite (können auch mehrere sein) aus zu schalten.
Ich finde weder bei den Beispielen noch woanders einen Hinweis das Topic beim Schalten von Empfängerseite aus zu ändern ist. Wenn ich Topic (Pfad zum physischen Schalter) ändere dann werde ich den Schalter kaum von EMpfängerseite aus betätigen können.
Wo denke ich hier falsch?
Kurzfassung: Hin- und Rückweg müssen m.E. verschieden sein.
Ablauf:
Über den einen Topic (cmnd bei Tasmota) kommen die Befehle AN das Gerät, NUR DAS lauscht da drauf.
Hat das Gerät (=Hardware) den Befehl erhalten, wird die Ausführung quittiert und zwar über einen ANDEREN Topic (die POWER-Topics bei Tasmota, zusätzlich dann ggf. noch tele bzw. stat).
Das ist v.a. dann wichtig, wenn man (wie du) einen externen Broker einsetzt und dann von verschiedenen Seiten schaltet.
Alle mir bekannten "guten" MQTT-Geräte machen das genau so, alles andere kann man zwar irgendwie abfangen, aber früher oder später ist sonst undurchsichtig, was warum passiert.
tja und genau das ist ja mein Problem das keine Hardware sondern nur ein dummy da ist:
ein dummy mit Uhrzeit auf fhem B mit dahinter liegenden Logik die auf fhem C zu dieser Uhrzeit ein Ventil öffnet.
das ist kein Problem und funktioniert
jetzt will ich auch auf fhem A das dummy von B sehen und ändern können...
sollte ja problemlos funktionieren denn wenn ich auf B was einstelle meldet es das A -> A meldet retour das geändert wurde und B tut nichts da es ja keine Änderung gibt und meldet auch nichts.
wenn ich auf A was ändere wird das B gemeldet und B ändert und gibt quasi die Änderung retour und A tut nichts da sich ja nichts geändert hat
das ganze sollte ja mit event-on-change-reading genauso funktionieren also keine Gefahr von Endlosschleifen
und nachdem in meinem Problem keine Hardware ist sondern alles in fhem als dummy würde die Lösung darin liegen ein 2. Reading anzulegen und das von B nach A zu spiegeln nur kommt da wieder das gleiche raus wenn ich z.B. vom reading zeit (B) auf reading state (A) denn B bestätigt natürlich auch zurück auf A wenn ich in A ändere und umgekehrt - also eigentlich kene andere Situation als wenn ich state auf state nehme.
Es wäre nur dann anders wenn eine Änderung nicht quittiert werden soll - ist aber nicht das wa sich will.
Ich bin anscheinend tatsächlich zu blöd um den Sinn dahinter zu verstehen.
gruß anton
In meiner Gedankenwelt sind "virtuelle" Geräte, die MQTT sprechen keine dummy, sondern vom TYPE MQTT2_DEVICE.
Falls du MQTT_GENERIC_BRIDGE einsetzt, um dem dummy MQTT beizubringen: Schau mal auf das Attribut "mqttForward" - der default verhindert nämlich bei TYPE dummy, dass es zu Schleifen kommt...
Hier wäre es vermutlich sinnvoll, "all" zu setzen (aber erst, wenn die Topics unterschiedlich sind!).
Und grundsätzlich: sobald du anfängst, weitere Events zu generieren (Wert kopieren), _könnte_ es ein Problem geben.
gut zu wissen das dummy einen unterschied macht - hab ich nirgendwo gelesen aber dann erklärt es warum ich einen dummy dazwischen schalten musste wie ich den GPIO vom Pi per MQTT_GENERIC_BRIDGE eingesetzt habe :-)
dann werde ich mal weiter experimentieren ;-) und hoffen das bei Fragen die für mich interessanten Infos rüberkommen :-)
danke anton
Zitat von: antonwinden am 19 März 2021, 08:53:48
gut zu wissen das dummy einen unterschied macht - hab ich nirgendwo gelesen aber dann erklärt es warum ich einen dummy dazwischen schalten musste wie ich den GPIO vom Pi per MQTT_GENERIC_BRIDGE eingesetzt habe :-)
Na ja, du hättest "einfach" andere Pfade für Kommando und Rückmeldung anlegen sollen und dann direkt den GPIO ansprechen. Diese "Kleinigkeit" war leider in der Doku zu MQTT_GENERIC_BRIDGE bisher nicht so deutlich hervorgehoben, der Maintainer und die User der ersten Stunde sahen das wohl als Selbstverständlichkeit an...
Meine Empfehlung wäre, mal ins Wiki zu MQTT_GENERIC_BRIDGE zu schauen bzw. das mal anzusehen, was das attrTemplate für die MGB mit "$base" macht. Ist zwar noch nicht fertig, aber evtl. (hoffentlich) jetzt deutlich besser verständlich als die damalige Doku.
Zitatdann werde ich mal weiter experimentieren ;-) und hoffen das bei Fragen die für mich interessanten Infos rüberkommen :-)
Viel Erfolg!