Wenn ich den Interval auf 0 gesetzt habe bleiben die automatischen Updates wie gewollt aus.
set <name> interval <integer>
Temporarely set the update interval. Will be overwritten by the attribute on restart. A value of -1 set the interval to the default given by attribute, a value of 0 disables the automatic update.
Wenn ich keine automatischen Updates möchte, wie kann ich dann ein Update manuell auslösen?
Wenn der Interval auf 0 gesetzt ist bewirkt der Befel
get status absolut nichts. Zumindest konnte ich nichts erkennen. Ob das wirklich so gewollt ist, sei mal dahingestellt.
Umgehungslösung:
Man setze den Wert für den Interval auf einen möglichst hohen Wert (die automatischen Updates bleiben nahezu aus), und triggert dann die manuellen Updates mit get satsusSobald ein Interval Wert gesetzt ist funktioniert auch get Satus wieder.
Evtl. gibt es noch eine besser Lösung.
Zitat von: birdy am 27 Mai 2024, 18:04:59Wenn der Interval auf 0 gesetzt ist bewirkt der Befel
Code Auswählen Erweitern
get status absolut nichts. Zumindest konnte ich nichts erkennen. Ob das wirklich so gewollt ist, sei mal dahingestellt.
Nein, ist so nicht gewollt.
Zitat von: birdy am 27 Mai 2024, 18:04:59Sobald ein Interval Wert gesetzt ist funktioniert auch get Satus wieder.
Zur Fehlereingrenzung: hast du das Interval hierbei via Attribut oder via Set-Befehl gesetzt?
Mit den Set Befehl, so wie es auch die oben eingeführte Beschreibung erklärt.
set <name> interval <integer>
Temporarely set the update interval. Will be overwritten by the attribute on restart. A value of -1 set the interval to the default given by attribute, a value of 0 disables the automatic update.
Ich habe bzw. will keine automatisch aktualisierte Readings, und habe darum Intervall auf 99999 gesetzt.
Wenn ich aktualisierte Reading benötige, rufe ich in 99_myUtils.pm
fhem("get ShellyYXZ status"); auf.
Die Readings werden dann auch ,,zügig" aktualisiert.
Mein Problem: Das aktualisieren der Reading dauert wohl ein paar Millisekunden.
Wenn ich direkt nach get status
ReadingsVal("ShellyYXZ","power_0,0)ausführe, bekomme ich noch die alten Werte, die von vor der Aktualisierung >:(
Hat jemand eine Idee, was man machen kann, um bei den ReadingsVal die neuen Werte zu bekommen?
Zitat von: birdy am 13 Juni 2024, 22:36:51Das aktualisieren der Reading dauert wohl ein paar Millisekunden.
Ja, das stimmt, weil die Anfrage "nonblocking" erfolgt.
Vorschlag: Benutze ein Notify, um auf aktualisierte Readings zu reagieren. Z.B. mit einem Trigger auf das Reading "uptime", weil dies bei jedem "get status" aktualisiert wird.
Schon gut, das die Anfrage "nonblocking" erfolgt.
Ist nicht wirklich ein Problem. Da ich aber mehrere Shelly's abfrage, benötige ich auch mehrere Notifiy's. Dachte, dass es evtl. noch eine andere Möglichkeit gibt.
Ich werde das also doch mit Notify's machen ;)
Vielen Dank für den Tipp
Ich habe es nun mit einem AT Befehl gelöst, die Lösung mit Notifys hat mich nicht überzeugt.
So kann ich alle Shellys auf einmal aktualisieren. Die Readings werden dann für alle parallel/nonblocking nachgeführt. 2 Sekunden später wenn die Readings nachgeführt sind, beginne ich mit der Auswertung.
Zitat von: birdy am 16 Juni 2024, 20:08:11Ich habe es nun mit einem AT Befehl gelöst
Schön, dass du eine für dich tragfähige Lösung gefunden hast.
Kannst du uns auch die Hintergründe für diese Anwendung erklären?
Der Hintergrund:
Ich ermittle von mehreren Shelly's den aktuellen Strom- "Verbrauch" auch von der PV. Je nach Situation treffe ich (bzw. FHEM) die Entscheidung einzelne Verbraucher hinzu oder wegzuschalten. Das Ziel ist es den Eigenverbrauch zu optimieren
ren.
Das ist insofern gefährlich, als sich die Energieerzeugung einer PV-Anlage innerhalb von Sekunden ändern kann. Zur weiteren Diskussion bitte die relativ neue Forenkategorie Energieerzeugung beachten, dort auch mal bei Wallboxen reinschauen.
Für das solare Überschussladen muss ich beispielsweise die relevanten Daten alle 5 Sekunden an die Wallbox übermitteln.
LG
pah
Dass eine PV-Anlage innerhalb von Sekunden die Energieerzeugung ändert, würde ich als vollkommen normal bezeichnen. Was daran gefährlich sein soll, kann und muss ich nicht verstehen.
Es geht hier darum, dass das Shelly Modul nicht so funktioniert wie es solle.
Es gibt aber einen Workaround dazu.
Zitat von: birdy am 22 Juni 2024, 21:14:24Dass eine PV-Anlage innerhalb von Sekunden die Energieerzeugung ändert, würde ich als vollkommen normal bezeichnen. Was daran gefährlich sein soll, kann und muss ich nicht verstehen.
Gefährlich wird das Konstrukt nur dann, wenn man nicht der Maxime "Sparen, koste es was es wolle" folgt und stattdessen eine wirtschafliche Rendite erzielen möchte. Durch ungünstige Profile von Erzeugung, Last und Ein-/Ausspeicherung kann nämlich der Bezug vom EVU steigen, statt zu sinken.
Im Übrigen geht es mit der Entwicklung des Moduls hier (https://forum.fhem.de/index.php?topic=137222.0) bald wieder weiter (Land ist in Sicht).
"Gefährlich" wird es auch dann, wenn man Verbraucher mit mehreren kW im Sekundentakt an- und ausschaltet.
Dafür sind die Shellys eher ungeeignet.
LG
pah
ZitatGefährlich wird das Konstrukt nur dann, wenn man nicht der Maxime "Sparen, koste es was es wolle" folgt und stattdessen eine wirtschafliche Rendite erzielen möchte. Durch ungünstige Profile von Erzeugung, Last und Ein-/Ausspeicherung kann nämlich der Bezug vom EVU steigen, statt zu sinken.
Ach so, unter gefährlich verstehe ich definitiv etwas anderes ;)
Aber ich weiss was Du meinst :)
ZitatIm Übrigen geht es mit der Entwicklung des Moduls hier bald wieder weiter (Land ist in Sicht)
Easy, kein Stress. Mein Workaround funktioniert ausgezeichnet. Aber schon mal vielen Dank für deine Arbeit.
Ich habe es erst jetzt gesehen.
Es scheint ein Problem zu geben. Bei jeden Aufruf von get status werden die Readings 2x gesetzt, zumindest die userReadings. ::)
Dies führ bei mir leider zu negativen Auswirkungen.
Gibt es eine Möglichkeit dies zu verhindern?
Ich konnte kein list finden.
Poste doch ein list, dann kann man vielleicht helfen...
Ohne Info: Trigger beim userReadings "eng genug" setzen...
Gruß, Joachim
Zitat von: birdy am 05 Juli 2024, 00:21:44Gibt es eine Möglichkeit dies zu verhindern?
Im Entwicklungs-Thread gibt es eine neue Beta-Version. Das Intervall-0-Thema sollte damit gelöst sein.
Hier der List meines Shelly
Internals:
DEF 10.10.10.122
FUUID 63190467-f33f-f4b3-ac8a-0b6915cbd6ede752
INTERVAL 99999
NAME ShellyEM3
NR 251
STATE 2456.81
TCPIP 10.10.10.122
TYPE Shelly
eventCount 11635
units 0
READINGS:
2024-07-05 17:50:27 Total_Energy 11368720
2024-07-05 17:50:57 apparentpower_0 1489.2
2024-07-05 17:50:57 apparentpower_1 1298.1
2024-07-05 17:50:57 apparentpower_2 143.4
2024-07-02 22:12:16 cloud enabled(connected)
2023-11-27 20:45:43 coiot enabled
2023-11-27 20:45:43 coiot_period 15
2024-07-05 17:50:57 current_0 6.23
2024-07-05 17:50:57 current_1 5.41
2024-07-05 17:50:57 current_2 0.6
2024-07-05 17:15:27 energyReturned_0 498440.6
2024-07-04 11:30:27 energyReturned_1 0.5
2024-06-17 08:11:47 energyReturned_2 0
2024-07-05 17:15:27 energyReturned_TTL 498441.1
2024-07-05 17:50:27 energy_0 2778580.4
2024-07-05 17:50:27 energy_1 1983060.8
2024-07-05 17:50:27 energy_2 7105519.9
2024-07-05 17:50:27 energy_TTL 11867161.1
2023-09-13 20:44:37 firmware v1.14.0
2024-07-04 23:59:50 myEnergy_TL 11856081.6
2024-07-05 17:50:57 myPower_D2 798
2024-07-05 17:50:57 myPower_D5 1569
2024-07-05 17:50:57 myPower_G 2456.81
2024-07-05 17:50:57 myPower_L0 2456.81
2024-07-05 17:50:57 myPower_L1 243.12
2024-07-05 17:50:57 myPower_L2 243.12
2024-07-05 17:50:57 myPower_L3 248.25
2024-07-05 17:50:57 myPower_L4 248.25
2024-07-05 17:50:57 myPower_L5 2444.86
2024-07-05 17:50:57 myPower_L6 2444.86
2024-07-05 17:50:57 myPower_L7 2454.91
2024-07-05 17:50:57 myPower_L8 2454.91
2024-07-05 17:50:57 myPower_L9 2452.09
2024-07-05 14:53:57 network <html>connected to <a href="http://10.10.10.122">10.10.10.122</a></html>
2024-07-05 14:53:31 network_disconnects 401
2024-07-05 17:50:57 network_rssi -61
2024-06-17 08:11:47 network_ssid xxxxxxxxxx
2023-11-27 20:45:43 network_threshold -70
2022-09-07 22:53:52 overpower 0
2024-06-17 08:11:47 overpower_0 off
2024-06-17 08:11:47 overpower_1 -
2024-06-17 08:11:47 overpower_2 -
2024-07-05 17:50:57 powerFactor_0 0.82
2024-07-05 17:50:57 powerFactor_1 0.9
2024-07-05 17:50:27 powerFactor_2 0.47
2024-07-05 17:50:57 power_0 1221.11
2024-07-05 17:50:57 power_1 1168.32
2024-07-05 17:50:57 power_2 67.38
2024-07-05 17:50:57 power_TTL 2456.81
2024-07-05 17:50:57 power_TTLc 2456.81
2024-07-05 17:50:57 reactivepower_0 852.4
2024-07-05 17:50:57 reactivepower_1 565.8
2024-07-05 17:50:57 reactivepower_2 126.6
2024-06-17 08:11:47 relay off
2024-06-19 23:06:08 source http
2024-07-05 14:53:57 state off
2024-06-17 08:11:47 timer 0
2024-07-05 17:50:57 voltage_0 239.36
2024-07-05 17:50:57 voltage_1 239.63
2024-07-05 17:50:57 voltage_2 239.52
2024-06-26 17:19:05 webhook_cnt 0
2024-06-26 17:19:05 webhook_ver 0
helper:
Sets config interval password reboot:noArg update:noArg name reset:disconnects on off toggle on-for-timer off-for-timer
Attributes:
ShellyName ShellyEM3
comment http://10.10.10.122/shelly
http://10.10.10.122/settings
http://10.10.10.122/status
interval 99999
model shelly3em
room Energie,Shelly
stateFormat myPower_G
userReadings myPower_G {ReadingsVal("ShellyEM3","power_0",0) + ReadingsVal("ShellyEM3","power_1",0) + ReadingsVal("ShellyEM3","power_2",0)},
myPower_L9 {ReadingsVal("ShellyEM3","myPower_L8",0)},
myPower_L8 {ReadingsVal("ShellyEM3","myPower_L7",0)},
myPower_L7 {ReadingsVal("ShellyEM3","myPower_L6",0)},
myPower_L6 {ReadingsVal("ShellyEM3","myPower_L5",0)},
myPower_L5 {ReadingsVal("ShellyEM3","myPower_L4",0)},
myPower_L4 {ReadingsVal("ShellyEM3","myPower_L3",0)},
myPower_L3 {ReadingsVal("ShellyEM3","myPower_L2",0)},
myPower_L2 {ReadingsVal("ShellyEM3","myPower_L1",0)},
myPower_L1 {ReadingsVal("ShellyEM3","myPower_L0",0)},
myPower_L0 {ReadingsVal("ShellyEM3","myPower_G",0)},
myPower_D5 {round((ReadingsVal("ShellyEM3","myPower_L0",0) +
ReadingsVal("ShellyEM3","myPower_L1",0) +
ReadingsVal("ShellyEM3","myPower_L2",0) +
ReadingsVal("ShellyEM3","myPower_L3",0) +
ReadingsVal("ShellyEM3","myPower_L4",0) +
ReadingsVal("ShellyEM3","myPower_L5",0) +
ReadingsVal("ShellyEM3","myPower_L6",0) +
ReadingsVal("ShellyEM3","myPower_L7",0) +
ReadingsVal("ShellyEM3","myPower_L8",0) +
ReadingsVal("ShellyEM3","myPower_L9",0))/10,0)},
myPower_D2 {round((ReadingsVal("ShellyEM3","myPower_L0",0) +
ReadingsVal("ShellyEM3","myPower_L1",0) +
ReadingsVal("ShellyEM3","myPower_L2",0) +
ReadingsVal("ShellyEM3","myPower_L3",0))/4,0)}
Zitat von: Starkstrombastler am 05 Juli 2024, 12:55:48Im Entwicklungs-Thread gibt es eine neue Beta-Version. Das Intervall-0-Thema sollte damit gelöst sein.
Es geht ja nicht direkt um das Intervall-0-Thema, sondern um get status.
Wenn die Readings durch ein Intervall aktualisiert werden, werden die userReadings nur 1x gesetzt. Wenn ich aber die das Update der Readings via get status triggere, werden die userReadings 2x gesetzt. Ich möchte nicht, dass die Shelly's automatisch via intervall aktualisiert werden, sondern nun exakt dann wenn ich es möchte.
Naja, wie gedacht, deine userReadings haben keinen Trigger!
Egal welcher Event (wie oft) kommt, werden diese "ausgeführt"...
Gruß, Joachim
Zitat von: MadMax-FHEM am 05 Juli 2024, 18:42:20Naja, wie gedacht, deine userReadings haben keinen Trigger!
Egal welcher Event (wie oft) kommt, werden diese "ausgeführt"...
Gruß, Joachim
Nein haben sie wirklich nicht, aber hatten sie auch früher nicht, als ich noch mit Intervall gearbeitet habe.
Habe ich richtig verstanden.
Wenn das Update durch einen Intervall ausgelöst wird dann = 1 Event =1 x userReadings setzen.
Und wenn das Update durch den Aufruf von get statsus ausgelöst wird dann = 2 Event =2 x userReadings setzen?
Schau im Eventmonitor welche und wie viele Events für/vom das Device kommen.
Ohne Trigger führt JEDER Event zur "Berechnung" aller userReadings...
Gruß, Joachim
Ergibt für mich keinen Sinn.....
Der Eventmonitor zeigt folgendes
2024-07-05 22:00:57 Shelly ShellyEM3 network_rssi: -66
2024-07-05 22:00:57 Shelly ShellyEM3 power_0: 444.58
2024-07-05 22:00:57 Shelly ShellyEM3 voltage_0: 236.25
2024-07-05 22:00:57 Shelly ShellyEM3 current_0: 2.3
2024-07-05 22:00:57 Shelly ShellyEM3 apparentpower_0: 542.2
2024-07-05 22:00:57 Shelly ShellyEM3 reactivepower_0: 310.4
2024-07-05 22:00:57 Shelly ShellyEM3 power_1: 166.57
2024-07-05 22:00:57 Shelly ShellyEM3 voltage_1: 237.09
2024-07-05 22:00:57 Shelly ShellyEM3 current_1: 0.94
2024-07-05 22:00:57 Shelly ShellyEM3 apparentpower_1: 222.1
2024-07-05 22:00:57 Shelly ShellyEM3 reactivepower_1: 146.9
2024-07-05 22:00:57 Shelly ShellyEM3 power_2: 388.59
2024-07-05 22:00:57 Shelly ShellyEM3 voltage_2: 236.87
2024-07-05 22:00:57 Shelly ShellyEM3 apparentpower_2: 462.6
2024-07-05 22:00:57 Shelly ShellyEM3 reactivepower_2: 251.0
2024-07-05 22:00:57 Shelly ShellyEM3 power_TTL: 999.74
2024-07-05 22:00:57 Shelly ShellyEM3 power_TTLc: 999.74
AAls ich den Shelly per Intervall getriggert habe, wurden die userReadings pro Trigger 1x berechnet. Und wenn ich mit get status triggere, werden die userReadings pro Trigger 2x berechnet.
Ist das nun Intervall oder get status?
Gruß, Joachim
Das ist der "get status"
INTERVAL 99999
Wie müsste deiner Meinung nach der korrekte Trigger aussehen?
Nur myPower_G wird durch DEVICE-readings berechnet. Also müsstest du auf Events von power_x reagieren. Das sind allerdings ggfs. auch 3 Events.
Wenn "get status" zuverlässig immer alle 3 power_x bringt reicht ggfs. ein myPower_G:power_0 statt myPower_G:power_ (die anderen userReadings müssen auch getriggert werden).
Das Reading power_TTL ist an sich schon der Wert deines userReadings myPower_G. Im Modul wird intern schon summiert, da der 3EM den Wert nicht liefert.
Gruß Ralf
Edit:
Nochmal in der CommandRef nachschauen.
power_TTL ist glaube ich der Wert aus dem 3EM und power_TTLc durch das Modul berechnet.
Dass der 3EM /Modul den kombinierten Wert auch liefert, ist mir bisher noch gar nie aufgefallen. Darum habe ich den Wert selbst berechnet. Danke für diesen Hinweis. :)
Ja alle 3 power_x werden jedes mal zuverlässig aktuallisiert.
Wenn ich versuche ein userReading mit einem Trigger zu versehen, wird es gar nicht mehr berechnet. Irgendetwas mache ich falsch. In denke, der Trigger müsste eine RegEx sein?
myPower_G:ShellyEM3.:*power_0:.*{ReadingsVal("ShellyEM3","power_0",0) + ReadingsVal("ShellyEM3","power_1",0) + ReadingsVal("ShellyEM3","power_2",0)}
oder wie genau müsste dieses userReading mit Berechnung, konkret aussehen um vom folgenden Event getriggert zu werden?
2024-07-05 22:15:27 Shelly ShellyEM3 power_0: 374.59
Da steht ein bißchen viel ":" drin. Ich hatte gestern auch den .* vergessen.
Mein Vorschlag als userReadings zum Test wäre:
myPower_G:power_0.* {
Spannend finde ich das Gesamtkonstrukt der voneinander abhängigen UserReadings - dass das sauber funktioniert ::)
Gruß Ralf
Super, vielen Dank, damit fuktioniert es wieder
myPower_G:power_0.* {ReadingsVal("ShellyEM3","power_0",0) + ReadingsVal("ShellyEM3","power_1",0) + ReadingsVal("ShellyEM3","power_2",0)},
myPower_L9:power_0.* {ReadingsVal("ShellyEM3","myPower_L8",0)},
myPower_L8:power_0.* {ReadingsVal("ShellyEM3","myPower_L7",0)},
myPower_L7:power_0.* {ReadingsVal("ShellyEM3","myPower_L6",0)},
myPower_L6:power_0.* {ReadingsVal("ShellyEM3","myPower_L5",0)},
myPower_L5:power_0.* {ReadingsVal("ShellyEM3","myPower_L4",0)},
myPower_L4:power_0.* {ReadingsVal("ShellyEM3","myPower_L3",0)},
myPower_L3:power_0.* {ReadingsVal("ShellyEM3","myPower_L2",0)},
myPower_L2:power_0.* {ReadingsVal("ShellyEM3","myPower_L1",0)},
myPower_L1:power_0.* {ReadingsVal("ShellyEM3","myPower_L0",0)},
myPower_L0:power_0.* {ReadingsVal("ShellyEM3","myPower_G",0)},
myPower_D5:power_0.* {round((ReadingsVal("ShellyEM3","myPower_L0",0) +
ReadingsVal("ShellyEM3","myPower_L1",0) +
ReadingsVal("ShellyEM3","myPower_L2",0) +
ReadingsVal("ShellyEM3","myPower_L3",0) +
ReadingsVal("ShellyEM3","myPower_L4",0) +
ReadingsVal("ShellyEM3","myPower_L5",0) +
ReadingsVal("ShellyEM3","myPower_L6",0) +
ReadingsVal("ShellyEM3","myPower_L7",0) +
ReadingsVal("ShellyEM3","myPower_L8",0) +
ReadingsVal("ShellyEM3","myPower_L9",0))/10,2)},
myPower_D2:power_0.* {round((ReadingsVal("ShellyEM3","myPower_L0",0) +
ReadingsVal("ShellyEM3","myPower_L1",0) +
ReadingsVal("ShellyEM3","myPower_L2",0) +
ReadingsVal("ShellyEM3","myPower_L3",0))/4,2)}
Ich dachte, ich müsste den Device Namen in den Trigger mit aufnehmen. Dies scheint aber nicht der Fall zu sein. Darum hat es bei mir mit Trigger nie funktioniert.
Das Konstrukt soll dazu dienen, Werte abzuspeichern, um die im nächsten Aufruf zur Verfügung zu haben: So kann ich dann Durchschnittswerte der letzten x Aufrufe berechnen um z.B. um das Aufheizen der Kaffeemaschine heraus zu filter. Das Konstrukt habe ich vor rund 2 Jahren gebaut. Möglicherweise gibt es für dieses Problem andere, bessere Lösungen. Das Ganze hat bisher auch wie gewünscht funktioniert, auch ohne expliziten Trigger in den userReadings. Erst jetzt, als ich von Intervall Triggerung auf "manuelle" Triggerung umgestellt habe, habe ich gesehen das die userReadings immer gleich 2 Plätze auf einmal nach hinten geschoben werden.