[Gelöst] Readings Update nur alle 5 Minuten?

[fhemthom]

Hallo,

ich stehe gerade vollkommen auf dem Schlauch Ich habe hier mehrere Tasmota Steckdosen mit dem basic_state_power_1 template eingerichtet:

Code Auswählen Erweitern


define Dyson_Ladegeraet_Kammer MQTT2_DEVICE DVES_1CE9AF
setuuid Dyson_Ladegeraet_Kammer 60d73503-f33f-bd54-da02-e312eaa186209576
attr Dyson_Ladegeraet_Kammer userattr structexclude wohnung wohnung_map
attr Dyson_Ladegeraet_Kammer autocreate 0
attr Dyson_Ladegeraet_Kammer comment NOTE: For on-for-timer SetExtensions are used. You may add on-for-timer option running on the device. The following is limited to 1h max duration, but will not affect future simple "on" commands:<br>on-for-timer {my $duration = $EVTPART1*10;; 'cmnd/cmnd/nous-a1-1CE9AF/Backlog POWER1 1;; delay '.$duration.';; POWER1 0'}<br>See the "Praxisbeispiele" in the wiki for "pulseTime1" alternative option and it's restrictions.
attr Dyson_Ladegeraet_Kammer devStateIcon on:FS20.on:off off:FS20.off:on
attr Dyson_Ladegeraet_Kammer icon hue_filled_outlet
attr Dyson_Ladegeraet_Kammer jsonMap POWER1:0 POWER2:0 POWER3:0 POWER4:0 Dimmer:0 Channel_0:0 Channel_1:0 Channel_2:0 Channel_3:0 Channel_4:0 HSBColor:0 Color:0
attr Dyson_Ladegeraet_Kammer model tasmota_basic_state_power1
attr Dyson_Ladegeraet_Kammer readingList tele/nous-a1-1CE9AF/LWT:.* LWT\
  tele/nous-a1-1CE9AF/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/nous-a1-1CE9AF/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/nous-a1-1CE9AF/INFO.:.* { $EVENT =~ m,^..Info[1-3]..(.+).$, ?  json2nameValue($1,'',$JSONMAP) : json2nameValue($EVENT,'',$JSONMAP) }\
  tele/nous-a1-1CE9AF/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  stat/nous-a1-1CE9AF/POWER1:.* state\
  stat/nous-a1-1CE9AF/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr Dyson_Ladegeraet_Kammer room Kammer
attr Dyson_Ladegeraet_Kammer setList off:noArg    cmnd/nous-a1-1CE9AF/POWER1 0\
  on:noArg     cmnd/nous-a1-1CE9AF/POWER1 1\
  toggle:noArg cmnd/nous-a1-1CE9AF/POWER1 2\
  setOtaUrl:textField cmnd/nous-a1-1CE9AF/OtaUrl $EVTPART1\
  upgrade:noArg   cmnd/nous-a1-1CE9AF/upgrade 1
attr Dyson_Ladegeraet_Kammer setStateList on off toggle
attr Dyson_Ladegeraet_Kammer wohnung Wohnung


der Server ist so konfiguriert:

Code Auswählen Erweitern


# activate MQTT2
define MQTT2_FHEM_Server MQTT2_SERVER 1883 global
setuuid MQTT2_FHEM_Server 60d6de18-f33f-bd54-ac21-a54633d0cba8d672


Jetzt möchte ich abhängig vom Stromverbrauch Aktionen ausführen, stelle aber fest, dass die Readings meiner Steckdosen nur alle 5 Minuten aktualisiert werden.

Nun dachte ich mir das mit:

Code Auswählen Erweitern


attr Dyson_Ladegeraet_Kammer event-on-change-reading .*
attr Dyson_Ladegeraet_Kammer event-min-interval .*:120


auf 2 Minuten ändern zu können, aber nix da. Die Readings werden nach wie vor nur alle 5 Minuten aktualisiert.
Habe ich einen Denkfehler? Was mache ich falsch?

vielen Dank!

[Beta-User]

Na ja, die eocr-Attribute filtern lediglich, was von außen kommt und erzeugen keine Readings bzw. updates, wenn nichts gemeldet wird.

Vermutlich ist die Ursache auf dem ESP zu suchen, https://tasmota.github.io/docs/Peripherals/#update-interval

[fhemthom]

Gnaaaaahhhh.....
Allerbesten Dank, das wird es sein!

Eine sonnige Woche noch 

[Beta-User]

  Danke gleichfalls!

Anmerkungen noch:

- ggf. bitte ein [gelöst] anbringen?
- Deine eocr-Attribute lesen sich (für mich) "komisch" (ohne die Readings zu kennen, ist das aber Kaffesatzleserei). Vermutlich willst du eigentlich nur einen Temperatursensor aktualisiert haben (mit einen Threashold?) und da dann ggf. auch wieder ein eher größeres Min-Intervall haben, damit die Logfiles nicht zu groß werden? Das ergäbe dann aber mAn. ganz andere eocr-Einstellungen...

[fhemthom]

Hallo,

nein, mein Ziel ist es das Ladegerät nach erfolgtem Ladevorgang abzuschalten (im Sinne von: wenn für 15 Minuten kein Strom mehr fließt dann ausschalten). Die derzeitigen Values sind erstmal nur testhalber eingesetzt, da muss ich mir noch überlegen wie ich das im Endeffekt haben möchte.

[Beta-User]

Ah, ok.

Dann wäre ggf. noch https://tasmota.github.io/docs/Commands/#power-monitoring (PowerDelta) interessant. Bei Ladegeräten muss man dann aber ggf. noch checken, wann/wie oft die ggf. in einen Erhaltungsmodus gehen, 15 Minuten "0 W" gibt es uU. dann gar nicht.

[Otto123]

Hi,

wie funktioniert das Ganze eigentlich ohne attr IODev? 
Oder ist das die Folge der IODev Diskussion?

Gruß Otto

[fhemthom]

Dann wäre ggf. noch https://tasmota.github.io/docs/Commands/#power-monitoring (PowerDelta) interessant. Bei Ladegeräten muss man dann aber ggf. noch checken, wann/wie oft die ggf. in einen Erhaltungsmodus gehen, 15 Minuten "0 W" gibt es uU. dann gar nicht.

schaue ich mir an - Danke für den Hinweis!

[Beta-User]

Hi,

wie funktioniert das Ganze eigentlich ohne attr IODev? 
Oder ist das die Folge der IODev Diskussion?

Gruß Otto

MAn. hat das hier mit IODev _nichts_ zu tun, es ist also etwas [OT]:
- Es kommen Werte an, nur eben nicht so, wie @fhemthom das erwartet hatte => Kommunikation an sich steht...
- Das "attr" macht die Verbindung "hart", hier ist aber mit großer Sicherheit das "etwas weichere" Reading vorhanden. Das für den laufenden Betrieb wichtige Internal wird dann eben aus dem Reading abgeleitet.

Zur Vermeidung "künftigen Unbills" _könnte_ es sinnvoll sein, das IODev-Attribut zu setzen, Pflicht ist das mAn. nicht, schon gleich nicht, wenn man nur M2S im Einsatz hat (was ich hier mal großzügig unterstelle; ohne Attribut ist das vermutlich "umbenennungsresistenter").

Ansonsten bleibt es bei dem, was ich an anderer Stelle schon geschrieben habe: Ich bin mir über die Auswirkungen und die Reichweite dieser Änderung auch noch nicht völlig im klaren...

[Otto123]

ich weiß sorry, mit dem Problem hat meine Anmerkung nichts zu tun. Mir ist die Art des Post etwas beim mitlesen aufgefallen. Das klang mir danach:
- Ich habe ein Device händisch angelegt anhand eines Templates
- Dann habe ich den MQTT2_Server definiert (die Kommentarzeile impliziert bei mir immer: ich habe es in die cfg geschrieben ...)

Meine MQTT2_Devices haben alle das IODev attr gesetzt und ich dachte beim "normalen" anlegen (autocreate am Server ist laut define auch nicht aus) kommt das immer mit!?

Damit ich hier einen thematischen Beitrag leiste: - daher kommen die 5 min - die könnte man auch verändern, ich würde es aber auch mit powerdelta machen

TelePeriod   See current value and force publish STATE and SENSOR message
0 = disable telemetry messages
1 = reset telemetry period to firmware default (TELE_PERIOD)
10..3600 = set telemetry period in seconds (default = 300)

Gruß Otto

[Beta-User]

Damit ich hier einen thematischen Beitrag leiste: - daher kommen die 5 min - die könnte man auch verändern, ich würde es aber auch mit powerdelta machen

Ich würde vermutlich beides machen: 10-15% powerDelta, aber dann nur eine telePeriode von 15 Minuten...

[OT2]
Da sind wir wieder bei dem General-Thema der "geschwätzigen Devices", hier allerdings mit etwas anderem "Einschlag": Es wissen einfach nach wie vor zu wenige Leute, dass (v.a. bei den MQTT-Geräten, aber auch anderen) häufig Einstellmöglichkeiten in der jeweiligen Firmware bestehen, mit denen man das beeinflussen kann. Bei den Shellies findet sich da wenigstens ein kurzer Hinweis in den "Praxisbeispielen", aber insgesamt ist "eocr+" im Allgemeinen und Tasmota im Speziellen in der Hinsicht wohl verbesserungsfähig...
Habe nur grade auch nicht die vertiefte Lust, mich des Themas anzunehmen ...
[/OT2]

[OT]

Meine MQTT2_Devices haben alle das IODev attr gesetzt und ich dachte beim "normalen" anlegen (autocreate am Server ist laut define auch nicht aus) kommt das immer mit!?

Afaik: war das nur früher so (indirekt über assignIoPort()?). Jetzt wird wohl "nur noch" das Reading gesetzt, wenn es nicht schon da ist und daraus dann das Internal abgeleitet. Müßte aber auch in den Code sehen bzw. das (wieder) austesten...
[/OT]

[rudolfkoenig]

Afaik: war das nur früher so (indirekt über assignIoPort()?). Jetzt wird wohl "nur noch" das Reading gesetzt, wenn es nicht schon da ist und daraus dann das Internal abgeleitet. Müßte aber auch in den Code sehen bzw. das (wieder) austesten...

Musst Du nicht, ist richtig so.
Wenn auch ein IODev Attribut vorhanden ist (== Benutzers Wille), dann ueberschreibt es das Reading.

[Beta-User]

Musst Du nicht, ist richtig so.
Wenn auch ein IODev Attribut vorhanden ist (== Benutzers Wille), dann ueberschreibt es das Reading.

Danke für die Klarstellung.

[hier OT]
Irgendwie fühle ich mich in dem Umfeld IODev und dem dispatch von "irgendwelchen" Nachrichten nach wie vor nicht so richtig sicher und könnte jetzt z.B. in dem Fall hier auf die Frage (aus User-Sicht) "soll ich denn jetzt auch das Attribut setzen oder lieber nicht?" auch keine wirklich abgesicherte Antwort geben...

Klar ist: Wenn es mehrere externe Server gibt, die identische Topics nutzen und mit MQTT2_CLIENT abgreifen (die Rooma-Sauger, z.B.), ist es mit einiger Sicherheit "sicherer", das auch via Attribut festzuzurren. Aber in allen anderen Fällen ist es für MQTT2_DEVICE _vermutlich_ flexibler, das Attribut nicht zu setzen ("self-healing"), wenn man das IO umbenennt oder von M2C auf M2S wechselt (vice versa, so in der readingList die CID nicht als Präfix steht).

Ergänzend aus DAM-Sicht:
Latent hatte ich auch überlegt, den dispatch-Mechanismus von MySensors umzustellen; aber abgesehen davon, dass das im Code etwas unglücklich "verschränkt" ist, habe ich da im Moment wegen dieser IODev-Geschichte Bauchschmerzen (da muss (!) es "hart" sein) und werde das erst mal nicht angehen. Zwischenzeitlich habe ich zwar verstanden, wie das mit dem dispatch aus fhem.pl heraus gemacht wird, bin mir auch nicht so richtig sicher, ob die Developer-Doku zu den zweistufigen Modellen wirklich vollständig ist und das halbwegs gut beschreibt. Hatte das vor längerem mal angesehen und mit meinem damaligen Wissen (=deutlich schlechter!) nicht verstanden, wie das funktionieren soll... Vermute, da gab es schon länger "room for improvement".