Entwicklungs-Thread Modul 36_Shelly.pm

Begonnen von Starkstrombastler, 24 Februar 2024, 12:15:05

Vorheriges Thema - Nächstes Thema

Starkstrombastler

Zitat von: bjbrill am 25 Juli 2024, 22:35:47bei mir spamt die Shelly 0-10V Dimmer den sytemlog voll, wenn er nachts ausgechatet ist.
Hintergrund: Die 0-10V dimmer können nicht komplett abschalten, deshalb muss man dann den Strom abschalten. dadurch enstehen nachts hunderte Fehlermeldungen:

Was ist der Hintergrund, warum schaltest du dem Shelly die Stromversorgung weg? Reicht es nicht, die Steuerspannung für den Ausgang auszuschalten?

Du könntest natürlich das Polling vorher ausschalten, dann laufen auch keine Anfragen mehr ins Nirwana:  set <shelly> interval 0
und zurück mit  set <shelly> interval -1
Oder du setzt den verbose level des Devices auf 1 (oder 0).

Jeder der Probleme mit seinem Netzwerk hat, wird wohl froh sein, wenn ein vorübergehend "verloren" gegangener Shelly sich alsbald wieder meldet. Von daher ist das Beibehalten des Polling schon sinnvoll.
Auch ein Unterdrücken von wiederholten Meldungen hat seine Tücken, weil die ursprüngliche Meldung weit nach hinten rutscht und dann nicht mehr so sichtbar ist.
Aber vielleicht gibt es ja irgendwo brauchbare Vorbilder für eine solche Situation...
IPC\Ubuntu + Fhem, 1wire, Shellies, Siemens Logo!, Z-Wave, PhilipsTV, Vu+duo2, KM200

gamauf

Zitat von: Starkstrombastler am 05 Juli 2024, 12:53:30Nach langer Ankündiung kommt hier die Beta-2 Version des Shelly-Moduls zum TESTEN.
...

Bin jetzt aus dem Urlaub zurück und hab die neue Version (danke dafür) eingespielt.
Habe jetzt neu die readings "energy_purchased" und "energy_returned".
Werde jetzt ein par Tage vergehen lassen müssen, bis ausreichend Werte protokolliert wurden.
Danke,
Rainer

caldir65

Zitat von: Starkstrombastler am 21 Juli 2024, 13:06:38Shelly Plus Addon: humidity, input und voltmeter wurden ergänzt
...
Ich bitte um Rückmeldungen, insbesondere auch dann wenn es keine Komplikationen gibt, denn das ist der angestrebte Zustand!

Moin,

sorry, hab's verschwitzt - humidity ist jetzt da (humidity_0) und hat auch einen plausiblen Wert.
Danke

Gruß
Christoph
Alte Techniker-Regel: "kaum macht man es richtig, funktioniert es auch"
------
Dell Wyse5070 ThinClient 16GBRam, 128GB SSD, Lubuntu 24.04.01LTS, fhem (aktuell), debmatic, Homematic-Devs, ConBee II und deConz, viele Shellys, Rademacher, NextCloud-Anbindung, FullyKioskBrowser+FUIP uvm.

Starkstrombastler

#48
Die neue Version 6.00 des Shelly Moduls ist ab dem 15.08.24 via regulärem Update verfügbar.

Zusammenfassung der wichtigsten Änderungen/Ergänzungen seit Version 5.21.1:
  • Neuorganisation der HTTP-Kommunikation (insbesonder bei Gen2-Devices): nächste Anfrage wird erst bei Abschluss der vorhergehenden Anfrage gestartet, reduzierte Anzahl zyklischer Timer
  • Verbesserung des Verhaltens von Dimmern und Leuchten
  • Unterstützung DNS-Namen in der Definition, anstatt IP-Adresse
  • Unterstützung Effekte bei RGBW2
  • Unterstützung 'humidity', 'input', 'voltmweter' bei Shelly Plus Addon
  • Unterstützung RangeExtender: Erweiterung Definition für gekoppelte Geräte, gekoppelte Geräte werden in Readings dargestellt; bei Non-FHEM Geräten wird 'no definiton' ausgegeben
  • Unterstützung SetExtensions
  • Unterstützung Readings 'energy_returned' und 'energy_purchased'  für Plus/Pro-Devices mit Leistungsmessung (PM)
  • Unterstützung Reading 'timer' für Shelly4Pro (Gen1)
  • Neu: Bei Geräten ohne Internetzugang wird im Reading 'firmware' ein Hinweis auf mögliches Firmware-Update ausgegeben
  • Neu: Befehl  'set ... config ap_enable|ap_disable'  zur Kontrolle des Access-Points (nur Gen2)
  • Neu: Durch Setzten des Attributs 'timeout' werden Readings mit den Response-Zeiten der HTTP-NonBlocking-Kommunikation angelegt (Max-Wert | letzter Wert); Readings werden mit 'set ... clear responsetimes' zurückgesetzt, durch Löschen des Attributes werden die Readings entfernt (timeout ist dann wieder auf Default-Wert=4sec)
  • Neu:  Mit Attribut 'interval_power' wird ein zusätzlicher Timer für den Abruf der Leistungswerte in kurzen Intervallen (min. 1sec) angelegt, nur ShellyPro3EM
  • Änderung:  ShellyPlusUni:  Readingname Analog Input
  • Änderung:  dimmbare Geräte/Kanäle können mit Befehl 'set ... pct 0' ausgeschaltet werden 
  • Änderung:  Wenn interval=0 gesetzt, wird state auf 'disabled' gesetzt
  • Änderung:  Reading 'timestamp' entfällt
  • Änderung:  Reading 'network_threshold' ist jetzt 'network_wifi_roaming', kann auch den Wert 'disabled' annehmen
  • Änderung:  Reading 'errors' ist jetzt 'error_EM', nur ShellyPro3EM
  • Änderung:  Internal 'SHELLY' ist jetzt Reading 'model_ID', neue Readings 'model_family', 'model_function', 'model_name'
  • Änderung:  Befehl 'set ... reset ...' ist jetzt 'set ... clear ...'
  • neue Geräte: ShellyPlus0-10VDimmer, ShellyProDimmer, ShellyPlusUni, Gen3-Devices, u.a.

Falls jemand Notifies oder andere Strukturen auf die geänderten Readings angelegt hat, möge er dies bitte ändern.

Die Befehlsreferenz (deutsche Fassung) ist entsprechend angepasst.

Die in diesem Thread hinterlegten Test-Versionen werden demnächst entfernt, da nicht mehr relevant.

Ich danke allen Testern und wünsche allen Nutzern des Shelly-Moduls viel Erfolg mit der verbesserten Version.
IPC\Ubuntu + Fhem, 1wire, Shellies, Siemens Logo!, Z-Wave, PhilipsTV, Vu+duo2, KM200

derdon23

Hi, vielen Dank für das Modul. Ich hab es schon eine Weile mit unterschiedlichen Shelly devices im Einsatz.

Unter anderem mit einem Pro3EM.
Dieser ist aufgrund des Einbaus im Zählerschrank leider WLAN mäßig grenzwertig unterwegs, funktionierte aber bisher problemlos.

Nach dem letzten Update verbleibt der pro3EM aber im STATE
Error: Network und es werden keine Verbrauchswerte mehr ausgelesen.

Das Gerät ist aber im WLAN problemlos erreichbar und witzigerweise werden auch 3 Werte (inttemp, WLAN rssi und uptime) kontinuierlich aktualisiert.

Kann ich irgendwas unternehmen um das zu beheben?

VB90

hat der Pro3 eventuell eine neue/andere IP bekommen?
Ich hatte das anfangs, bin dann dazu übergegangen, allen Shelly feste IP einzutragen.

Probleme mit dem Netzwerk habe ich auch öfter bei einer entfernten Installation.
Dort hilft bislang nur ein (wiederholter) Neustart des Shelly. Bei fest installieren Geräten nicht immer ganz einfach machbar.

vb
Man muss das Rad nicht neu erfinden, nur wissen wie es gedreht wird.

Starkstrombastler

Zitat von: derdon23 am 06 September 2024, 12:22:25Nach dem letzten Update verbleibt der pro3EM aber im STATE
Error: Network und es werden keine Verbrauchswerte mehr ausgelesen.

Das Gerät ist aber im WLAN problemlos erreichbar und witzigerweise werden auch 3 Werte (inttemp, WLAN rssi und uptime) kontinuierlich aktualisiert.
Ich habe tatsächlich in meiner Testumgebung den gleichen Effekt, ohne dass ich das bemerkt habe. Ursache ist der letzte Bug-Fix (use Sub::Util), der mit dem morgigen Update auf Modul-Version 6.00.4 zurückgenommen wird. Der ursprüngliche Anlass wird auf andere Weise gelöst.

Die Funktion subname wird also nicht mehr genutzt:
Zitat von: Elektrobastler am 02 September 2024, 10:29:41"Undefined subroutine &Sub::Util::subname called at ./FHEM/36_Shelly.pm line 6466."

Zitat von: VB90 am 06 September 2024, 18:07:31hat der Pro3 eventuell eine neue/andere IP bekommen?
Ich hatte das anfangs, bin dann dazu übergegangen, allen Shelly feste IP einzutragen.
Statt fester IP können die Shellies auch mit ihrem DNS-Namen definiert werden, siehe CommandRef.
IPC\Ubuntu + Fhem, 1wire, Shellies, Siemens Logo!, Z-Wave, PhilipsTV, Vu+duo2, KM200

derdon23

Super, Dankeschön.
Ich hab das Update installiert und melde mich, falls ich den Fehler nochmals sehen sollte.

derdon23

Leider scheint das Problem noch zu bestehen.

Gestern Abend scheint der Pro3EM kurz disconnected gewesen zu sein und das Gerät im FHEM bleibt danach im "STATE Error: Network".

In den Readings stehen als letzte updates z.B.:
Active_Power_S  402.8  2024-09-10 20:17:26
und der counter für disconnects ging kurz danach um 1 hoch (der stand vorher auf 2):
network_disconnects  3  2024-09-10 20:18:16
Es werden weiterhin einige wenige Readings aktualisiert:

inttemp 49.8 2024-09-11 16:12:08
network_rssi -59 2024-09-11 16:12:08
uptime 2738829 2024-09-11 16:12:23

und das Gerät selbst ist im Netzwerk auch problemlos erreichbar.

Starkstrombastler

Zitat von: derdon23 am 11 September 2024, 16:19:35Gestern Abend scheint der Pro3EM kurz disconnected gewesen zu sein und das Gerät im FHEM bleibt danach im "STATE Error: Network".
Ich denke, wir haben hier ein anderes Problem, wenngleich mit ähnlichen Folgen. Auf Grund des Disconnects bleibt der Timer für die Zählerwerte stehen.
Weil beim ShellyPro3EM mehrere Timer laufen, werden einige Readings noch weiter aktualisiert.
Zum Wiederbeleben:  Die Timer werden durch 'set ... interval ..' oder 'attr  ... [interval|interval_power] ...' neu gestartet.

Bezüglich der Ursache dieses Verhaltens bin ich noch am suchen....
IPC\Ubuntu + Fhem, 1wire, Shellies, Siemens Logo!, Z-Wave, PhilipsTV, Vu+duo2, KM200

tobi01001

Zitat von: Starkstrombastler am 11 September 2024, 23:50:36Bezüglich der Ursache dieses Verhaltens bin ich noch am suchen....
Hi,

Die Ursache dürfte darin liegen, dass die neuen Timer in der Callback gesetzt werden. Wenn durch einen Netzwerkfehler der Non-Blocking Aufruf nicht durchgeht, bzw die Callback nicht aufgerufen wird, wird der Timer nicht neu gestartet.
Als Lösung könntest du den den/die Timer selbst im Aufruf selbst neu setzen (als Backup) und dann in der Callback dediziert löschen (passiert eh schon) und mit dem gewünschten Intervall neu setzen.


Gruß,
Tobi
FHEM@UbuntuServer on Lenovo ThinkCentre M900 [i5-6500T / 8GB RAM] MySQL-DbLog, Grafana, FTUI3 / HmIP incl. CCU3 / LGESS / Wärempumpe über TA CMI und CANoE / Shellies u.v.m.

Starkstrombastler

Zitat von: tobi01001 am 12 September 2024, 15:24:12Wenn durch einen Netzwerkfehler der Non-Blocking Aufruf nicht durchgeht, bzw die Callback nicht aufgerufen wird, wird der Timer nicht neu gestartet.
Ja, genau so ist - manchmal braucht man eben einen Anstoss in die richtige Richtung.
Zur Lösung wird der/die Timer im Fall eines Timeouts einfach neu gestartet... 

Eine aktualisierte Version werde ich hier als Beta-Version zur Verfügung stellen.
IPC\Ubuntu + Fhem, 1wire, Shellies, Siemens Logo!, Z-Wave, PhilipsTV, Vu+duo2, KM200

det.

Sorry, war lange nicht hier - und hab eine dumme Frage: was kann ich tun, dass ein Shellyplusi4 das Event Eingang ändert Status von on zu off (oder umgekehrt) sofort meldet und nicht nach gefühlt über 30 s später?
LG
det.

Starkstrombastler

Zitat von: det. am 27 September 2024, 12:27:05Sorry, war lange nicht hier - und hab eine dumme Frage: was kann ich tun, dass ein Shellyplusi4 das Event Eingang ändert Status von on zu off (oder umgekehrt) sofort meldet und nicht nach gefühlt über 30 s später?
Dafür sind die Actions das richtige Instrument. Richte mit Hilfe des Moduls die Actions auf dem Shelly ein:
attr <name> webhook <hook>
set <name> actions create info
set <name> actions create index
    oder
set <name> actions create all


Mit create all werden die Actions disabled angelegt, du musst dann nach Bedarf aktivieren.
IPC\Ubuntu + Fhem, 1wire, Shellies, Siemens Logo!, Z-Wave, PhilipsTV, Vu+duo2, KM200

caldir65

Moin,

ich habe einen ShellyPlus1 mit Addon. Daran angeschlossen ist ein Reedkontakt. Wenn ich jetzt einen Magnet entsprechend anlege, kann ich in der Oberfläche vom Shelly eine Reaktion sehen, jedoch kommt davon nichts in fhem an.

Ein
http://192.168.1.147/rpc/Shelly.GetStatusgibt mir als Ergebnis
ble    {}
cloud   
connected    false
input:0   
id    0
state    false
input:100   
id    100
state    true
mqtt   
connected    false
switch:0   
id    0
source    "init"
output    false
temperature   
tC    54.5
tF    130
sys   
mac    "441793CF9254"
restart_required    false
time    "14:07"
unixtime    1727611636
uptime    685
ram_size    268812
ram_free    128928
fs_size    393216
fs_free    110592
cfg_rev    9
kvs_rev    0
schedule_rev    0
webhook_rev    0
available_updates    {}
reset_reason    3
wifi   
sta_ip    "192.168.1.147"
status    "got ip"
ssid    "Caldir_MacAran_IoT"
rssi    -79
ws   
connected    false
wobei der input:100 der Reed ist, in diesem Fall geschlossen

Hier einmal die aktuelle Definition:
defmod ShellyPlus1_Schlafzimmer Shelly 192.168.1.147
attr ShellyPlus1_Schlafzimmer DbLogExclude .*
attr ShellyPlus1_Schlafzimmer event-on-change-reading .*
attr ShellyPlus1_Schlafzimmer group Shelly
attr ShellyPlus1_Schlafzimmer model shellyplus1
attr ShellyPlus1_Schlafzimmer room Arbeitszimmer,Schlafzimmer

setstate ShellyPlus1_Schlafzimmer off
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:30 addon sensor
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:30 ap ShellyPlus1-441793CF9254 disabled open
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:30 ap_clients disabled
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:30 ble enabled
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:30 cloud disabled
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:58:29 firmware v1.4.2(check internet for firmware v1.3.3)
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:29 input off
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:30 input_0_function follow
setstate ShellyPlus1_Schlafzimmer 2024-09-29 14:07:34 input_1 on
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:30 input_1_mode switch straight enabled
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:30 input_mode switch straight enabled
setstate ShellyPlus1_Schlafzimmer 2024-09-29 14:09:34 inttemp 54.5
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:28 mac 44:17:93:CF:92:54
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:28 model_ID SNSW-001X16EU
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:28 model_family Plus/Gen2
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:28 model_function switch
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:28 model_name Shelly Plus 1
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:30 name ShellyPlus1_Schlafzimmer
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:29 network <html>connected to <a href="http://192.168.1.147">192.168.1.147</a> (Wifi)</html>
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:29 network_ip-address 192.168.1.147
setstate ShellyPlus1_Schlafzimmer 2024-09-29 14:08:34 network_rssi -73
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:29 network_ssid Caldir_MacAran_IoT
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:30 network_wifi_roaming -80
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:29 relay off
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:29 source init
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:29 state off
setstate ShellyPlus1_Schlafzimmer 2024-09-29 14:09:34 uptime 824
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:30 webhook_cnt 0
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:29 webhook_ver 0

Könnte das evtl. auch entsprechend mit eingebaut werden?

Danke und Gruß
Christoph
Alte Techniker-Regel: "kaum macht man es richtig, funktioniert es auch"
------
Dell Wyse5070 ThinClient 16GBRam, 128GB SSD, Lubuntu 24.04.01LTS, fhem (aktuell), debmatic, Homematic-Devs, ConBee II und deConz, viele Shellys, Rademacher, NextCloud-Anbindung, FullyKioskBrowser+FUIP uvm.