Dieser Thread dient der Diskussion des Moduls 36_Shelly.pm. Wer es nicht nutzen will, soll es bitte einfach sein lassen und sich entsprechender Äußerungen enthalten.
Eine weitere Dokumentation findet sich im Wiki https://wiki.fhem.de/wiki/Modul_Shelly
LG
pah
Hallo Pah,
ich finde das Shelly Modul sehr interessant. Ich kann damit doch auch eine Wechsel- oder Kreuzschaltung im Haus realisieren,
sofern ich das Modul dort einsetze, wo DauerPhase ist...... richtig ?
Bislang habe ich nämlich ein Homematic Teil mit Custom Firmware.....
VG
mcfly
Klar, das geht. https://www.facebook.com/groups/331714694256669/
LG
pah
Hallo pah,
ich habe sei einiger Zeit auch angefangen Shelly 1 einzusetzen, vor allem wegen der kleinen Bauform.
Das Modul läuft völlig geräuschlos, herzlichen Dank dafür !
Einzige Anregung/Wunsch für eine kommende Version wäre dass bei verbose 3 nicht so viele Meldungen kommen.
Zur Zeit habe ich die Devices alle auf v 0 gesetzt, läuft ja :)
Bei mir finde ich zur Zeit immer mehr Verwendung für die Dinger ....
LG
Heiko
Zitat von: Prof. Dr. Peter Henning am 15 November 2018, 10:24:39
[...]
Im Test ist Modul Version 1.5. - die dann an die neue Firmware angepasst wird.
LG
pah
Hi pah,
Gibt es die Möglichkeit, an den Testversionen teilzuhaben? Wäre ein Grund, die Beta-Firmware zu installieren.
Gruß, Tom
https://forum.fhem.de/index.php/topic,90950.msg857203.html#msg857203
Habe den ersten Shelly 1 eben in einer Kreuzschaltung mit der 1.5 beta 1 in Betrieb genommen (wegen Username und Passwort auf der Weboberfläche des Shelly). Funktioniert auf Anhieb und bis jetzt ohne Probleme!
Vielen Dank an pah für dieses tolle Modul. Ist wesentlich einfacher einzusetzen als MQTT...
Grüße Cluni
Danke, das war das Ziel :D. Ist als Version 1.5 eingecheckt.
Den anderen Thread habe ich geschlossen, weil ich keinen Bock auf Leute habe, die auf akademischen Titeln herumreiten...
LG
pah
Es wird immer Leute geben, die etwas zu nörgeln haben. Einfach abperlen lassen. Ich habe auch schon festgestellt, dass Leute auf akademische Titel manchmal allergisch reagieren.
Mit MQTT wäre die Rückmeldung beim manuellen Schalten zwar direkt im System, aber mal ganz ehrlich, wann und wozu braucht man das direkt? Wenn die Shellys selber keinen Timer unterstützen würden und ich damit eine Treppenhausschaltung (über Notify) realisieren wollen würde, ok - aber das ist ja nicht der Fall, da es direkt im Shelly realisierbar ist. Ist dieser interne Timer eigentlich direkt in deinem Modul einstellbar, oder geht das nur über die Webpage des Shelly? Habe in der Commandref auf Anhieb nichts dazu gefunden.
Grüße Cluni
Klar wird das im Modul unterstützt, on-for-timer und off-for-timer sind implementiert. Ich habe gerade eine ausführliche Doku in Arbeit, siehe hier: https://wiki.fhem.de/wiki/Shelly-Aktoren
LG
pah
Und das sind die internen Timer des Shelly? Ich hatte vermutet, dass du das dann selber ein/ausschaltest. Und das wesentliche: Das gilt doch dann nur für diesen einen Schaltvorgang. Ich meine die Einstellung auf der Webpage des Shelly unter Timer: "Auto on" und "Auto off" - das machen die ja dann auch autark beim Betätigen des Schalters ohne Fhem.
Das ist wieder der Beweis, dass es hier die Experten nicht für umsonst gibt.
Vielen Dank für das Modul.
Das pro und Contra im Wiki sagt alles.
@Cluni so ist dies Gesellschaft eben!
Super Sache.
pah
Vg Denny
ZitatUnd das sind die internen Timer des Shelly?
Ja, und das geht pro Schaltvorgang, auch das ist richtig.
Auto-On und Auto-Off sind davon nicht berührt. Die kann man aber mit set config auch im Modul setzen. Ich müsste nur mal nachsehen, wie das dann genau lautet.
LG
pah
Das hört sich gut an. Könnte man dort noch ein pull-down Menü für die möglichen Register einbauen? [emoji1360]
Gesendet von iPhone XR mit Tapatalk
Will ich eigentlich nicht generell (gibt es bei HomeMatic ja auch nicht). Konfigurationsänderungen sollten etwas schwieriger bleiben, sonst kann zu leicht Mist passieren. ich werde aber ein paar Beispiele in das Wiki aufnehmen.
LG
pah
Ok, das ist auch wahrscheinlich besser so.
Die möglichen Settings sind die, die auch auch in der Rest-API bei Shelly finde und die kann ich auch alle verwenden? Also beispielsweise "auto_off 10", wenn ich möchte, dass das Licht 10s nach dem Einschalten automatisch wieder ausgehen soll?
Grüße Bernd
Ja, genau so.
LG
pah
Konnte es gerade mal testen - klappt hervorragend!
Vielen Dank!
Hallo pah,
demnächst (5. Dez) soll ja ein Temperature/Humidity Sensor kommen:
https://shelly.cloud/shelly-humidity-and-temperature/
Ich hab den einfach mal bestellt in der Hoffnung, dass er mit dem Modul auch (irgendwann mal) gehen wird :)
Sollte das "einfach" so gehen (habe mich mit Shelly und dem Modul noch nicht wirklich beschäftigt) oder ist es geplant den zu integrieren (war meine Hoffnung als ich ihn "einfach so mal gekauft/bestellt habe ;) )!?
Danke, Joachim
Kommt sicher nicht mit dem Modul - das ist eines für Aktoren. Zuviel überfüssiger Kram für Sensoren.
LG
pah
Schade, der Name des Moduls ließ nicht darauf schließen... ;)
Dann mal sehen wie ich das hinkriege...
Gruß, Joachim
Falls der neue Shelly Sensor MQTT spricht, hast du ja eine Alternative.
Im Zweifelsfall werde ich den Modulnamen ändern ...
Habe gerade die Zusicherung von Dimitrov bekommen, dass ich am Montag die neue Version der Firmware zum Testen bekomme.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 25 November 2018, 14:46:31
Im Zweifelsfall werde ich den Modulnamen ändern ...
Habe gerade die Zusicherung von Dimitrov bekommen, dass ich am Montag die neue Version der Firmware zum Testen bekomme.
LG
pah
War wie der Smiley ausdrücken sollte nicht ernst gemeint aber bei einem anderen Namen hätte ich vermutlich tatsächlich nicht nachgefragt... ;)
@Papaloewe: werde ich sehen, wenn er da ist...
Gruß, Joachim
ich habe gerade Version 1.6 des Moduls eingecheckt. Deutlich verbesserte Einstellung der prozentualen Öffnung im Roller-Mode. Vor allem unterstützt das Modul die oben angesprochene Beta-Version 1.4 der Firmware. Mit Autokalibrierung und Messung des Öffnungsstandes des Rollladens - und zwar auch dann, wenn dieser manuell auf eine andere Position gefahren wurde.
Bitte dazu als model=shelly2beta einstellen.
LG
pah
Zitat von: Cluni am 18 November 2018, 18:25:26
https://forum.fhem.de/index.php/topic,90950.msg857203.html#msg857203
Habe den ersten Shelly 1 eben in einer Kreuzschaltung mit der 1.5 beta 1 in Betrieb genommen (wegen Username und Passwort auf der Weboberfläche des Shelly). Funktioniert auf Anhieb und bis jetzt ohne Probleme!
Vielen Dank an pah für dieses tolle Modul. Ist wesentlich einfacher einzusetzen als MQTT...
Grüße Cluni
Sooooo, mein erster und vorerst einziger verbauter Shelly 1 hat gerademal 8 Tage im Treppenhaus überlebt. Heute Morgen ging das Licht nicht mehr an und die Sicherung war draußen. Nach Einschalten der Sicherung blieb sie zwar drin, aber der Shelly ist nicht erreichbar übers Web und über die Schalter schaltet er auch nicht mehr. Werde ihn heute Abend mal wieder ausbauen und dann zerlegen. Das ist jetzt echt ernüchternd... :-(
Werde berichten.
Gruß Bernd
Zitat von: Cluni am 26 November 2018, 08:45:15
Sooooo, mein erster und vorerst einziger verbauter Shelly 1 hat gerademal 8 Tage im Treppenhaus überlebt. Heute Morgen ging das Licht nicht mehr an und die Sicherung war draußen. Nach Einschalten der Sicherung blieb sie zwar drin, aber der Shelly ist nicht erreichbar übers Web und über die Schalter schaltet er auch nicht mehr. Werde ihn heute Abend mal wieder ausbauen und dann zerlegen. Das ist jetzt echt ernüchternd... :-(
Psssst, falscher Thread. Hier geht es um das FHEM-Modul.
Hardware Diskussion hier: https://forum.fhem.de/index.php/topic,93252.0.html
Sehe ich nicht so - wenn die Leute sich einen Shelly kaufen wollen und ggf. nur diesen Thread hier lesen, dann finde ich das eine wichtige Information, die man auch hier kundtun darf und sollte....
Aber danke für den Hinweis. ;)
Zitat von: Cluni am 26 November 2018, 08:53:30
Sehe ich nicht so - wenn die Leute sich einen Shelly kaufen wollen und ggf. nur diesen Thread hier lesen, dann finde ich das eine wichtige Information, die man auch hier kundtun darf und sollte....
Aber danke für den Hinweis. ;)
Dann sag mir doch mal was ein Hardware-Deekkt mit dem
FHEM Modul zu tun hat?
Es sind extra zwei Threads eröffnet worden. einer für die Hardware, einer für das Modul...
Ach weißt du, man kann alles tot quasseln. Manch einer, der nur überlegt sich neue Schalter zuzulegen und diesen Thread hier findet und nicht den anderen, wird für so einen Hinweis vielleicht dankbar sein. Sticht dir der eine Post so sehr im Auge, dass du direkt hier deswegen eine große Diskussion anfangen musst? DAS gehört auch nicht hier hin und wenn es dir nur um die Zurechtweisung meiner Person deshalb gehen würde, dann hättest du das richtigerweise per PN tun können/müssen....
Zitat von: Cluni am 26 November 2018, 09:04:06
Ach weißt du, man kann alles tot quasseln. Manch einer, der nur überlegt sich neue Schalter zuzulegen und diesen Thread hier findet und nicht den anderen, wird für so einen Hinweis vielleicht dankbar sein. Sticht dir der eine Post so sehr im Auge, dass du direkt hier deswegen eine große Diskussion anfangen musst? DAS gehört auch nicht hier hin und wenn es dir nur um die Zurechtweisung meiner Person deshalb gehen würde, dann hättest du das richtigerweise per PN tun können/müssen....
Hi,
ICH habe die Diskussion nicht angefangen. Ich hab nur einen Hinweis auf den richtigen Thread gepostet. ;-) Das hatte nichts mit Zurechweisung und sonstwas zu tun. war nur ein Hinweis...
Es gab Anfanfs einen Thread für alles der Shellys. pah hat dann extra die Threads aufgetrennt um die Übersicht zu wahren...
Wat denn?
Ein Streit, und ich bin nicht dabei?
Jibt et nich.
Zitatpah hat dann extra die Threads aufgetrennt um die Übersicht zu wahren
Weniger wegen der Übersicht, als um nicht mehr von irgendwelchen Halbwissenden darüber belehrt zu werden, dass sie das Modul nicht brauchen.
Also: Kurzer Hinweis hier, falls etwas Wichtiges in den anderen Thread kommt - ist ok. Aber bitte nicht einfach doppelt posten.
LG
pah
Hallo,
seit gestern sind meine Shelly1 ankegommen.
Zur Zeit sind sie im Testaufbau und alles funktioniert soweit bestens.
Ich würde die Aktoren gerne "disablen" können, wenn sie nicht angeschlossen sind.
In den attr finde ich keine Einstellen zum disablen?
36_Shelly.pm 17846 2018-11-25 19:18:37Z phenning
Übersehe ich irgend etwas?
VG
Olaf
Ja. Commandref lesen. "interval" auf Null, dann wird nichts gepollt.
LG
pah
Guten Morgen,
nutzt sonst noch jemand den Shelley eins in Verbindung mit dem Home Bridge Modul, Um ihn an Apple Home zu nutzen? Das funktioniert bei mir grundsätzlich gut, aber der Status des Schalters kommt in Apple Home nicht an. Oder liegt das an den Begrenzungen des Shelley Moduls und ich muss auf den MQTT modus umsteigen? Das will ich eigentlich vermeiden denn das Modul macht bei mir Out of the Box einen super Job.
Gruß
Jan
Was ist denn als Polling Interval eingestellt ? Welches Reading wertet das Home Bridge Modul aus ? Oder welchen Event ?
LG
pah
Guten Morgen,
Zunächst mal vielen Dank an den Prof. pah für die viele Mühe mit dem Shelly Modul.
Ich habe eine Frage: ich habe einen Shelly 2 und will ihn einfach im Relais Modus betreiben. Also zwei unabhängige Relais und im Idealfall dafür zwei unabhängige FHEM devices benutzen können. Ich stelle mir das so vor das man mit einem
Attr. Shelly channel 0
zb den Kanal und damit das Relais auswählen kann.
Ist sowas in Planung? Oder geht das gar schon und ich weiß einfach nur nicht wie?
Danke und schöne Grüße...
Tom
Es geht schon: Commandref / attr defchannel.
Danke ... hab keine Anleitung dafür gefunden. Ich probier es heute Abend ...
Hallo, Sensoren soll 36_Shelly nicht haben, wurde gesagt.
Wie sieht es mit dem Shelly Bulb aus? In scope oder ex scope?
Hi,
Sorry bin bzgl Shelly auf Neuland. Modul läuft an sich super mit einem Shelly1. Jetzt geht nur das Erkennen bei Schalterbetätigung nicht. Ich möchte ungern nur deswegen auf MQTT umsteigen, daher ist mein Ziel beim Shelly Modul zu bleiben.
Im FHEM-Wiki steht "Hinweis: Mit der aktuellen Version des Moduls unter Verwendung der Beta-Firmware von Shelly vom 13.11.2018 wird die Position auch nach manueller Betätigung gemeldet."
Ich verstehe das so, dass wenn ich die Shelly-Beta vom 13.11. installiere, es dann geht, wie ich es "brauche". Ich habe nun ne halbe Ewigkeit in der Facebook Gruppe von Shelly nach der Beta-Url gesucht und nicht gefunden.
Kann mir hier jemand weiterhelfen?
Danke und VG
Gesendet von meinem ONEPLUS A6003 mit Tapatalk
Zitat von: Florie am 09 Dezember 2018, 18:03:11
Im FHEM-Wiki steht "Hinweis: Mit der aktuellen Version des Moduls unter Verwendung der Beta-Firmware von Shelly vom 13.11.2018 wird die Position auch nach manueller Betätigung gemeldet."
Das bezieht sich auf den Shelly2 und die manuelle Verstellung, wenn dieser als Rollladen-Aktor verwendet wird.
"position" bezieht sich auf den Rollladen.
Der Schaltzustand des Shelly 1 = "state" wird auch nach manueller Betätigung erkannt - allerdings erst nach dem nächsten Poll (einstellbar durch das Intervall).
LG
pah
Super, danke euch. Das war einfach. Läuft, vielen Dank.
Hallo pah,
ich habe bei meinem bisher einzig verbauten Shelly (zu den anderen bin ich immer noch nicht gekommen) das Problem, dass das Modul (v1.6) von Zeit zu Zeit das Passwort für den Webzugang des Shelly vergisst. In state steht dann "error" und Schaltvorgänge bewirken nichts. Nach der erneuten Eingabe des Passworts funktioniert er wieder wie gehabt. Habe bis jetzt noch nicht herausgefunden, wie und wann es dazu kommt. Ein Neustart von Fhem scheint zumindest nicht das Problem zu sein. Hast du da einen Tipp für mich?
Grüße Bernd
Leider nicht. Denn dafür nutze ich eine externe Routine, die (mutmaßlich) von Rudi stammt.
LG
pah
Hmmmm, tritt das Problem denn nur bei mir auf, oder ist dir oder jemand anderem dieses Problem denn auch schon mal aufgefallen?
Bei der Fritzbox zum Beispiel habe ich das Problem noch nicht gehabt bis jetzt.
Übrigens gibt es seit heute eine neue Firmware.
Grüße, Bernd
Gesendet von iPhone XR mit Tapatalk
Von mir als eher stiller Mitleser erstmal ein dickes Danke für das Modul - das funktioniert mit meinen Shelly2 an den Rolläden ganz hervorragend.
Ich hätte noch einen kleinen Entwicklungswunsch beizusteuern, weiss aber natürlich nicht, wie weit das machbar ist.
Es wäre super, wenn es ein kleines Mapping für die Prozentwerte gäbe. Das Problem - zumindest bei meinen Rolläden, vermutlich werden das aber auch andere haben, ist, dass nach der Kalibrierungsprozedur der Positioners die 50% halt nicht 50% sind, weil der Rolladen, wenn er denn zu ist, natürlich auch noch ein ganzes Stück nachläuft, bis die Lamellen endgültig aufeinander sitzen, und der Motor dann noch entsprechend nachdrehen kann. Das hat dann leider zur Folge, dass 50% Öffnung eher 20-25% entsprechen. Soweit ich das Überblicken kann, scheint der Shelly zumindest die reinen Laufzeitunterschiede zwischen hoch- und runterfahren durch das Gewicht des Rolladens auszugleichen (da bin ich mir allerdings nicht sicher). Ähnliche Mechanismen sind ja im "Rollo" Modul vorhanden.
Wenn man da jetzt eine Kurve mit 5 Punkten (das sollte ausreichen denke ich) hinterlegen könnte (den Rest kann man dann ja interpolieren), wäre das bestimmt gut lösbar. Mir ist bewusst, dass man bestimmt auch mit Notifys irgendwie zurechtkommen würde, aber ich denke das wird dann fummelig, wenns an die Steuerung per alexa-fhem geht.
Das Ganze ist natürlich sehr vom verwendeten Rollladen abhängig, und auch keine generische Funktion des Moduls. Das Mapping müsste ferner in beide Richtungen durchgeführt werden.
Und damit stellt sich die Frage, wie wir das in andere Module (etwa HomeMatic) einbringen. Das derzeit in der Entwicklung befindliche Modul für Rollladensteuerung (siehe hier) ist dafür schon wieder zu mächtig.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 09 Dezember 2018, 18:17:52
"position" bezieht sich auf den Rollladen.
Der Schaltzustand des Shelly 1 = "state" wird auch nach manueller Betätigung erkannt - allerdings erst nach dem nächsten Poll (einstellbar durch das Intervall).
LG
pah
Hat sich da etwas geändert?
Bei meinem Shelly1 steht dort nur ok
Internals:
CFGFN
CHANGED
DEF 192.168.178.52
DURATION 0
INTERVAL 60
MOVING stopped
NAME Eckeschalter
NR 989
STATE OK
TCPIP 192.168.178.52:80
TYPE Shelly
READINGS:
2018-12-18 14:14:20 cloud disabled
2018-12-18 14:16:04 firmware v1.4.2
2018-12-20 05:48:11 network connected
2018-12-20 19:31:47 relay on
2018-12-18 14:14:20 relay_0 on
2018-12-20 19:31:47 state OK
Attributes:
devStateIcon !off:lamp@yellow:off off:lamp@white:on
model shelly1
stateformat relay
behebt das.
LG
pah
Danke
Hallo zusammen,
ich würde gerne meine Shelly 1 und meine Shelly 4 Pro in Homekit/Homebridge abbilden wollen.
Homebridge läuft bereits, jedoch habe ich keinen Schimmer, wie ich nun die Shelly 1 + 4 dort einbinden kann.
Hat das schon jemand erarbeitet?
Vielen Dank & schöne Grüße,
Mike
Bitte keine doppelten Posts.
pah
Sorry, falls ich mit meiner Frage hier falsch bin:
Brauche ich zur lokalen Ansteuerung eines Shelly 1 einen Taster oder einen Schalter?
Vielen Dank.
Zitat von: Mave am 25 Dezember 2018, 17:12:47
Sorry, falls ich mit meiner Frage hier falsch bin:
Brauche ich zur lokalen Ansteuerung eines Shelly 1 einen Taster oder einen Schalter?
Vielen Dank.
Geht beides. Man muss im Webuinterfase nur den Modus umstellen.
Zitat von: mele am 25 Dezember 2018, 17:51:04
Geht beides. Man muss im Webuinterfase nur den Modus umstellen.
Super, vielen Dank.
Hallo, ich habe da mal eine Verständnisfrage...
ich habe einen Shelly1 bei mir installiert und mit
attr stateformat relay
die Anzeige geändert. soweit sogut.
Ich habe eine strucure "ST_overview_light" eingerichtet, in der alle meine Lampen enthalten sind.
mit
attr clientstate_behavior relativeKnown
und
attr clientstate_priority on off
frage ich nun ab, ob irgendeine Lampe "on" oder "off" ist. Dies nutze in TabletUI in meiner Hauptübersichtsseite. So sehe ich sofort ob irgendwo noch licht an ist.
Wenn ich den Shelly1 nun in meine structure aufnehme, funktioniert sie nicht mehr. Die structure ist immer "on"
Weiss jemand warum das so ist?
Gruß
Carsten
Interessante Frage, kann ich so nicht beantworten. Sollten wir aber herausfinden, ggf. muss ich beim Shelly1 einfach standardmäßig den state durch den Schaltzustand ersetzen.
LG
pah
Super, wenn ich helfen kann, sag mir nur was Ich tun soll.
Zitat von: Prof. Dr. Peter Henning am 27 Dezember 2018, 03:04:42
ggf. muss ich beim Shelly1 einfach standardmäßig den state durch den Schaltzustand ersetzen.
LG
pah
Das halte ich auch im Vergleich zu Aktoren anderen Serien (Homematic, Z-Wave, FS20) für sinnvoll. Der state ist bisher dauerhaft OK (zumindest bei meinen Shelly1 und zum Glück - ich hatte mit den 4 Stück noch keinerlei Probleme).
Großen Dank an den Modul Entwickler, auch für den Fingerzeig in Richtung der Hardware.
Zitat von: Cluni am 18 November 2018, 18:25:26
https://forum.fhem.de/index.php/topic,90950.msg857203.html#msg857203
Habe den ersten Shelly 1 eben in einer Kreuzschaltung mit der 1.5 beta 1 in Betrieb genommen (wegen Username und Passwort auf der Weboberfläche des Shelly). Funktioniert auf Anhieb und bis jetzt ohne Probleme!
Vielen Dank an pah für dieses tolle Modul. Ist wesentlich einfacher einzusetzen als MQTT...
Grüße Cluni
Ich habe ebenfalls Shellyuser in den Atributen gesetzt und unter set Shelly das Password gesetzt , nach neusart von Fhem muss ich jedensmal neu das Passwort setzen damit State auf OK geht und nicht auf ERROR bleibt.wie kann ich das Passwort in den Atributen setzen damit es nach neustart von Fhem verbleibt?
Hallo zusammen, ich muss mich hier mal als stiller Mitleser des Forums und dieses Threads äußern.
Ich bekomme leider überhaupt keinen Einstieg bei der Fhem konfiguration des Shelly 2.
Shelly lässt sich über die App/Webinterface wunderbar schalten, nur leider bekomme ich diesen in Fhem nicht konfiguriert.
Hier ein Auszug aus den Internals:
STATE Error
TYPE Shelly
network not connected
Hier ein Auszug aus den Readings:
network not connected
state Error
Hier ein Auszug aus den Attributes:
mode relay
model Shelly 2
Ich hoffe jemand kann mir helfen.
Danke nochmal an pah für das astrreine Modul !
Zeig doch ein List
2018.12.28 21:02:58 1: [Shelly_status] has error gethostbyname <192.168.178.66> failed
2018.12.28 21:03:18 1: [Shelly_status] has error gethostbyname <192.168.178.66> failed
2018.12.28 21:03:38 1: [Shelly_status] has error gethostbyname <192.168.178.66> failed
Das ist kein List oben in Fhem list <Devicename> eingeben.
Über den Browser kannst du ihn steuern?
Betreffend das Passwort: Das wird in einer separaten Datei verschlüsselt abgelegt. Sollte nach einem Save config auch beim Neustart verfügbar sein. Achtung: Diese Routine stammt nicht von mir, ggf. mal bei Rudi König anfragen.
Zum Thema des Verbindungsfehlers: Offenbar ist das eine falsche IP-Adresse, kann man doch aus der Fehlermeldung ablesen.
LG
pah
In der Fehlermeldung steht "gethostbyname"
Unterscheidet das Modul ob Name oder IP definiert ist?
Laut der Fehlermeldung scheint es die IP als Name Auflösen zu wollen. Und hier scheint der DNS dann nichts zu liefern.
Gesendet von meinem Doogee S60 mit Tapatalk
Über diese IP-Adresse kann ich aber shelly über den Browser erreichen.
Vielmehr glaube ich, dass es bei mir ein Problem mit dem Json package gibt.
2018.12.29 14:57:01 1: [Shelly_status] has error gethostbyname <192.168.178.66> failed
2018.12.29 15:01:37 1: [Shelly_status] invalid JSON data
2018.12.29 15:02:27 1: [Shelly_configure] has invalid JSON data
ZitatVielmehr glaube ich, dass es bei mir ein Problem mit dem Json package gibt.
Sorry, aber das ist einfach Quatsch. Dieses Perl package ist seit vielen Jahren auf tausenden von Systemen im Einsatz.
Wenn die Kiste nicht erreichbar ist, bekommt das Modul natürlich keine gültigen JSON-Daten...
Ich tippe mal, dass hier einfach ein Anfängerfehler bei der Definition gemacht wurde - vielleicht die IP-Adresse als <IP-Adresse> angegeben ?
Aber da uns bisher kein Listing vorgelegt wurde, können wir natürlich nur raten.
LG
pah
P.S.: Ich habe gerade eine neue Version eingecheckt, die beim Shelly1 von sich aus den state auf den Schaltzustand setzt. Sollte funktionieren, unerwünschte Effekte bitte melden.
Zitat von: Prof. Dr. Peter Henning am 29 Dezember 2018, 16:23:01
Ich tippe mal, dass hier einfach ein Anfängerfehler bei der Definition gemacht wurde - vielleicht die IP-Adresse als <IP-Adresse> angegeben ?
Aber da uns bisher kein Listing vorgelegt wurde, können wir natürlich nur raten.
Da kann jemand hellsehen.
Gerade bei mir getestet, dann steht bei mir im log
2018.12.29 16:26:31 1: [Shelly_status] has error gethostbyname <192.168.178.52> failed
Zitat von: Prof. Dr. Peter Henning am 29 Dezember 2018, 16:23:01
Ich tippe mal, dass hier einfach ein Anfängerfehler bei der Definition gemacht wurde - vielleicht die IP-Adresse als <IP-Adresse> angegeben ?
Aber da uns bisher kein Listing vorgelegt wurde, können wir natürlich nur raten.
Das würde auch erklären warum versucht wird per Name aufzulösen.
Aber wie Du schreibst, ohne vollständiges listing ist alles nur aus der Glaskugel geraten.
Ich habe eine sehr gute Glaskugel.
LG
pah
Internals:
CFGFN
DEF <192.168.178.66>
DURATION 0
INTERVAL 60
MOVING stopped
NAME WZ_Deckenlampe
NR 3238
STATE Error
TCPIP <192.168.178.66>:80
TYPE Shelly
READINGS:
2018-12-29 23:06:11 network not connected
2018-12-29 23:06:11 state Error
Attributes:
icon light_ceiling
mode relay
model shelly2
room 80_Wohnzimmer,Licht
Tobias, falls du es noch nicht verstanden hast, nimm < und > aus der DEF, da darf nur die IP stehen.
Gesendet von meinem Doogee S60 mit Tapatalk
Hallo pah,
nach der Änderung des Moduls, klappt es auch mit meiner Structure.
Vielen Dank für die Hilfe und das tolle Modul
Carsten
Hallo zusammen,
nutze das Shelly Modul und es funktioniert bei mir einwandfrei mit einem Shelly Plug und einen Shelly 1.
Erstmal vielen Dank für das Modul.
Ich möchte nun, wenn der Shelly 1 eingeschaltet wird einen zweiten Aktor schalten.
Dieser Aktor soll möglichst "sofort" auf ein Zustandsänderung des Shellys reagieren.
Ich habe in der Beschreibung von dem Modul gelesen, dass mit der Beta Firmware möglich sein soll.
Leider weiß ich nicht genau wie das funktionieren soll.
Ich nutze die Firmware 1.4.3 (Release). Kann diese schon die Zustandänderung an FHEM übermitteln?
Leider habe keine Beta Firmware auf der Seite von Shelly gefunden :-[
Ich hoffe ich bin hier richtig ::)
LG
Tobias
Stell Mal Interval auf 1. Dann geht das auch sofort ;)
Gesendet von meinem ONEPLUS A6003 mit Tapatalk
ZitatIch habe in der Beschreibung von dem Modul gelesen, dass mit der Beta Firmware möglich sein soll.
Leider weiß ich nicht genau wie das funktionieren soll.
Ich auch nicht, und ich habe auch weder etwas von "Übermitteln" noch von einer "Zustandsänderung von Shelly 1" geschrieben.
Das Modul 36_Shelly.pm pollt den Aktor in regelmäßigen Abständen - wobei ein Intervall von einer Sekunde ziemlich gefährlich ist. Denn es wird jeweils ein http-Request abgesetzt. Je nach Latenz im Netz, je nach Auslastung des Shellys etc. kann dies zu Fehlern und zum Ausbremsen des FHEM-Systems führen. Muss nicht - aber keine Garantie.
Die Shellys senden nur AKTIV eine Zustandsänderung, wenn sie im MQTT-Modus sind.
Allerdings kann auch diese verzögert sein. Damit Menschen etwas als "sofort" empfinden, sollte die Latenz < 0,4 Sekunden sein. Das ist auch mit MQTT nicht garantiert.
Fazit: Wer etwas "gleichzeitig" schalten will, sollte den Schaltbefehl auf anderem Weg an FHEM übermitteln, und die Schaltbefehle von dort aus (fast) gleichzeitig übermitteln.
LG
pah
Vielen Dank für deine Erläuterung du hast mir sehr weitergeholfen.
Hallo zusammen.
Danke nochmal für die Hilfe.
Seit heute Mittag lässt sich mein Shelly 2 nicht mehr schalten. Der State steht auf Error.
Damit die beteiligten nicht nochmal die Glaskugel benutzen müssen hier das Listing:
Internals:
DEF 192.168.178.66:80
DURATION 0
INTERVAL 60
MOVING stopped
NAME WZ_Deckenlampen
NR 64
STATE Error
TCPIP 192.168.178.66:80
TYPE Shelly
READINGS:
2018-12-30 00:00:10 cloud disabled
2018-12-30 00:00:10 firmware v1.4.3
2019-01-01 23:24:07 network connected
2019-01-01 12:59:45 overpower_0 false
2018-12-30 00:03:22 overpower_0|1 false
2019-01-01 09:38:40 overpower_1 false
2019-01-01 13:22:00 power 0
2019-01-01 13:22:00 relay_0 false
2018-12-30 00:03:22 relay_0|1 true
2019-01-01 09:38:40 relay_1 false
2019-01-01 23:38:15 state Error
Attributes:
defchannel 0
mode relay
model shelly2
room 80_Wohnzimmer,90_Alexa,Licht
shellyuser admin
Gib mal das Passwort neu ein...
Gesendet von iPhone XR mit Tapatalk
Moin zusammen,
ich möchte gern meinen Shelly2 mit einem Toggle versehen, der beim Drücken eines Funktasters ausgeführt wird.
Leider habe ich dazu gerade eine Blockade im Hirn.
Folgendes DoIf tut es in einem Fall nicht und im anderen bootet der Shelly neu. :'(
(["XMI_158d00015635fb:\bclick\b"] and [shelly_Number1:relay_0])
(set shelly_Number1 off 0)
(set shelly_Number1 on 1)
DOELSE
(set shelly_Number1 off 1)
(set shelly_Number1 on 0)
Vielen Dank für die Unterstützung!!
Zitat von: Prof. Dr. Peter Henning am 29 Dezember 2018, 09:56:17
Betreffend das Passwort: Das wird in einer separaten Datei verschlüsselt abgelegt. Sollte nach einem Save config auch beim Neustart verfügbar sein. Achtung: Diese Routine stammt nicht von mir, ggf. mal bei Rudi König anfragen.
Hi,
habe meine Shellys noch nicht und nutze gerade die Wartezeit um mich etwas einzulesen.
Wg. des verlorenen Passwortes: eventuell habt ihr das Device zwischenzeitlich umbenannt?
Das Passwort wird in einem Schlüssel der den Devicenamen enthält abgelegt. Nach dem Umbenennen ist dieser nicht mehr verfügbar.
Das könnte man modulseits abfangen wie z.B. hier
http://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/72_FB_CALLMONITOR.pm
#################################
# If Device is renamed, copy the password data
sub
FB_CALLMONITOR_Rename($$)
{
my ($new, $old) = @_;
my $old_index = "FB_CALLMONITOR_".$old."_passwd";
my $new_index = "FB_CALLMONITOR_".$new."_passwd";
my $old_key =getUniqueId().$old_index;
my $new_key =getUniqueId().$new_index;
my ($err, $old_pwd) = getKeyValue($old_index);
return undef unless(defined($old_pwd));
setKeyValue($new_index, FB_CALLMONITOR_encrypt(FB_CALLMONITOR_decrypt($old_pwd,$old_key), $new_key));
setKeyValue($old_index, undef);
}
P.S.
das Passwort wird unverschlüsselt abgelegt
(https://wiki.fhem.de/wiki/DevelopmentModuleAPI)
Für die Verschlüsselung ist das jeweilige Modul zuständig.
Im Callmonitor ist auch eine entsprechende Diggest MD5 Implementierung enthalten.
Gruß Stefan
I stand corrected: Das Passwort wird ohne Zusatzaufwand nicht verschlüsselt.
Zwar sind inzwischen so viele Kollisionsangriffe auf MD5 bekannt, dass von der Sicherheit des im Callmonitor verwendeten Verfahrens nicht auszugehen ist. Aber als nötig erachte ich das schon deshalb nicht, weil das Passwort an den Shelly im Klartext übertragen wird.
LG
pah
Hallo zusammen,
ich habe mir vor kurzem einen Shelly 2 für meine Rolladenaktoren bestellt. (Leider ist er noch auf dem Postweg.)
Ich frage mich ob man einen der Schalteingänge vom Shelly als Tür/Fensterkontakt nutzen kann.
Ich würde das mit einem Reedkontakt und einem Magneten an der Tür an den S1/2 Schalteingang des Shellys hängen wollen.
Lässt es die SW zu den Schalter ohne Aktion durch den Shelly selbst zu nutzen und per FHEM den Zustand auszulesen und Aktionen auszuführen?
Viele Grüße,
Ulli
Prinzipiell ja - aber davon rate ich dringend ab. Denn der Magnetkontakt müsste 230 V schalten, dafür sind die Reed-Relais nur in Sonderfällen geeignet. Und man muss 230 am Fensterrahmen haben...
LG
pah
Hm, wenn meine Annahme richtig ist dürfte doch am Shelly der Schaltkontakt keinen Strom fließen lassen, sondern nur die anliegenden Spannung messen.
d.h. es fließt auch kein Strom über das Reed-Relay.
Die Spannung habe ich eh am Fenster da ja das Rollo dort montiert ist.
Zitat von: ulli am 04 Januar 2019, 18:20:42
Hm, wenn meine Annahme richtig ist dürfte doch am Shelly der Schaltkontakt keinen Strom fließen lassen, sondern nur die anliegenden Spannung messen.
d.h. es fließt auch kein Strom über das Reed-Relay.
Die Spannung habe ich eh am Fenster da ja das Rollo dort montiert ist.
Ganz dünnes Eis. Finger weg.
Wenn Du schon unbedingt mit einem Reedkontakt den Shelly schalten willst, dann über den Umweg eines (12- oder 24V) Relais. Dafür brauchst Du zwar zusätzlich eine Kleinspannung am Fenster, ist aber sicherer. Frag mal den Elektriker Deines Vertrauens, was er von Deinem Plan hält...
EDIT: Deine Frage gehört übrigens hierhin (https://forum.fhem.de/index.php/topic,93252.0.html).
Gruß
Uwe
Ich habe da mal eine Verständnisfrage.
Ich habe nun mehrere Shelly1, Shelly2 und einen Shelly4 in Betrieb. Der Shelly4 schaltet bei mir im Stall mehrere Aussenleuchten, diese sind auch über einen Schalter bedienbar. Funktioniert soweit wunderbar.
Für Fhem helfe ich mir da mit einem Dummy, welcher meinen Schalter simuliert und ein simples DOIF schaltet dann.
Wie habt Ihr das gelöst? Auch ein Dummy für jeden Ausgang mit dem dazugehörigem DOIF oder Notify? Oder gibt es da eine einfachere Lösung ?
Gruß
Carsten
Hallo Carsten,
Schau mal nach readingsProxy
Hi Det,
ok jetzt habe ich 4 Kanäle die ich theoretisch Schalten könnte.
Hier mal exemplarisch ein list :
Internals:
DEF Shelly4Pro:relay_2
DEVICE Shelly4Pro
NAME rp_StallbeleuchtungLinks
NOTIFYDEV global,Shelly4Pro
NR 1346
NTFY_ORDER 50-rp_StallbeleuchtungLinks
READING relay_2
STATE off
TYPE readingsProxy
CONTENT:
Shelly4Pro 1
READINGS:
2019-01-06 14:23:44 lastCmd off
2019-01-06 14:24:28 state off
Attributes:
alias Aussenbeleuchtung-Links
room Stall
setList on off
Wie kann ich relay_2 denn jetzt sagen "set .... on 2" ...
Irgendwie habe ich gerade da eine Schraube verkehrt... führt mich mal einer auf den richtigen Weg, bevor meine Frau mir das Notebook um die Ohren haut ;)
Gruß
Carsten
Hallo Carsten,
die Kanäle schaltest du wie folgt an:
set SHELLY4ProDEINNAME on 0
set SHELLY4ProDEINNAME on 1
set SHELLY4ProDEINNAME on 2
set SHELLY4ProDEINNAME on 3
& aus mit "set SHELLY4ProDEINNAME off 0".
Desweiteren würde ich dir empfehlen folgende Attribute zu setzen (zumindest das Erste dürfte notwendig sein):
model => shelly4
stateFormat => {ReadingsVal($name,"relay_1","")}
Mit defchannel => 1 setzt du Kanal 1 als Default Channel. D.h. klickst du oben auf on / off => wird Kanal 1 geschaltet.
Die 1 kannst du natürlich beliebig zwischen 0 und 3 wählen.
Gruß,
Mike
Das ist aber nicht die Antwort auf seine Frage... ::)
Hallo zusammen,
ich integriere gerade meinen ersten Shelly als Rolloaktor.
Da ich es logischer finde das 0% (pct) offen ist habe ich das Attribut pct100 auf closed gestellt.
Scheinbar ist da noch ein Bug im Modul. Wenn ich jetzt auf 25% stelle fährt das Rollo auf 3/4 geschlossen :)
Auch das State Reading zeigt dann moving down an anstatt moving up...
Kann sich jemand das mal anschauen?
Hätte ich machen können, wenn ich es ein paar Tage vorher gewusst hätte. Derzeit: Bitte in Geduld üben, habe eine Kongressmesse mit mehr als 10.000 Besuchern zu organisieren.
LG
pah
Hallo,
ich wollte noch mal fragen, ob mir mal einer mit dem readingsProxy auf die Sprünge helfen kann, oder eine andere Lösung eines Dummy / Doif Devices zu geben?
Wie gesagt, ich habe da irgendwie eine schraube im Kopf.
Gruß
Carsten
Und noch mal ich ;)
Ist es geplant, die anderen Shelly Komponenten (mir geht es insbesondere um den Rauchmelder mit Temperaturmessung) auch mit in das Modul zu implementieren?
So für heute morgen genug fragen...
Lg
Carsten
Hi,
hat noch jemand das Problem dass die Shellys seit Update auf 1.4.4 im Status "moving_up" oder "moving_down" hängen bleiben bzw. der State auch auf "ERROR" steht?
Greets
Marcus
EDIT:
Nevermind - wie es ausschaut ist wohl parallel gestern oder vorgestern der model-type "shelly2beta" den ich noch gesetzt hatte rausgeflogen. Bis gestern gings noch.
Vermutlich ein Bug im Modul bei der Auswertung der alten möglichen Werte und de,m zugehörigen Forward auf das neue Verhalten.
Zitatgestern oder vorgestern
Unsinn. Diese Version ist seit dem 29.12.2018 eingecheckt - und natürlich fliegt "beta" raus, wenn es "beta" nicht mehr gibt. Das Modul funktioniert mit der aktuellen Firmware astrein.
pah
Tjoa dann hatte ich seitdem nicht upgedated - trotzdem nicht schön, dass das Modul dann den Dienst verweigert ;)
Konstruktiver Tipp: sowas kann man problemlos forwarden und im Log nen Warning ausgeben - das spart auf Nutzerseite dann stundenlange Fehlersuche ;)
ZitatKonstruktiver Tipp: sowas kann man problemlos forwarden und im Log nen Warning ausgeben
Prima, dann schlage ich doch vor, ein eigenes Modul zu schreiben und das so zu handhaben.
pah
Danke für den konstruktiven Tipp, werd ich mal angehen ;)
Im Ernst: wieso reagierst Du denn auf einen praktischen, vielfach in der Softwareentwicklung genau so genutzten Weg so allergisch?
Moin zusammen,
zunächst ein herzliches Dankeschön an pah für das tolle Modul.
Ich habe heute meinen ersten Shelly1 in Betrieb genommen.
Mein "Problem" hat nichts mit dem Modul zu tun sondern mit dem Shelly1.
Dennoch hoffe ich in diesem Thread auf einen Hinweis.
Ich habe den Shelly1 an einem Lichtschalter angebracht - wohl gemerkt Schalter und nicht Taster.
Wenn ich jetzt über FHEM das Licht ein- oder ausschalte, reagiert der Shelly1 auf die nächste Umschaltung am Schalter nicht sondern erst auf das zweite Umschalten.
Das ist jetzt kein riesen Problem aber ein kleiner Schönheitsfehler, weil man im Vorbeilaufen nicht mal eben schnell das Licht aus- bzw. einschalten kann.
Ist das ein Problem des Schalters und wäre das mit einem Taster behoben oder gibt es dafür eine Einstellung?
Vielen Dank.
Grüße Mave
Zitat von: Mave am 19 Januar 2019, 17:02:45
Ist das ein Problem des Schalters und wäre das mit einem Taster behoben oder gibt es dafür eine Einstellung?
Wurde hier (https://forum.fhem.de/index.php/topic,93252.msg889723.html#msg889723)schon mehrfach beantwortet.
Gruß
Uwe
Super, vielen Dank. Das war die Lösung.
Was mir dabei aufgefallen ist, die Möglichkeiten der App und der Weboberfläche sind unterschiedlich. Zum Beispiel kann man über die Weboberfläche den Shelly rebooten, über die App nicht.
Das wäre nützlich gewesen, nachdem ich in der FritzBox eine andere IP für den Shelly vergeben habe.
In der Weboberfläche kann man auch eine feste IP vergeben. Diese Option fehlt in der App.
Meine Güte, mach Dir doch bitte mal klar, auf welchen Umwegen sich die App mit dem Shelly verbindet. Das ist ein Sicherheitsleck, also sollte man froh über jede nicht vorhandene Einstellmöglichkeit sein.
LG
pah
Ich habe jetzt auf MQTT umgestellt.
Hallo
Ich nutze schon einiger Zeit das Modul ohne Probleme.
Mir ist in letzter Zeit öfters beim starten des FHEM Servers im log eine Meldung aufgefallen.
PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4684.
Ich habe sie erstmal ignoriert weil ich auch nicht die Zeit hatte danach zu suchen.
Das hat sich nun geändert und ich habe mal im global das attr stacktrace auf 1 gesetzt um zu gucken wo die Warnung her kommt.
2019.01.30 19:41:17 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4684.
2019.01.30 19:41:17 1: stacktrace:
2019.01.30 19:41:17 1: main::__ANON__ called by fhem.pl (4684)
2019.01.30 19:41:17 1: main::readingsBulkUpdateIfChanged called by ./FHEM/36_Shelly.pm (650)
2019.01.30 19:41:17 1: main::Shelly_status called by ./FHEM/36_Shelly.pm (604)
2019.01.30 19:41:17 1: main::__ANON__ called by FHEM/HttpUtils.pm (606)
2019.01.30 19:41:17 1: main::__ANON__ called by fhem.pl (734)
Es scheint das es aus dem Shelly Modul kommt, beim pollen des Status.
Hier ein list des Shellys
Internals:
CHANGED
DEF 192.168.0.35
FUUID 5c488521-f33f-e69a-9f66-04417c4d0fd0541d
INTERVAL 60
NAME F_Licht_EG
NR 413
STATE off
TCPIP 192.168.0.35:80
TYPE Shelly
OLDREADINGS:
READINGS:
2018-12-05 12:02:50 cloud disabled
2018-12-05 13:05:01 config default_state=last
2018-12-05 12:02:50 firmware v1.3.5
2019-01-30 17:13:54 network connected
2019-01-30 19:37:11 relay off
2019-01-30 19:37:11 state off
Attributes:
icon hue_filled_gu10_par16
model shelly1
room Flur
Schon einmal vielen Dank für die Mühe und des super Moduls.
Gruß Alex
Auf den ersten Blick sieht es so aus, als ob die FW des Shelly ein wenig veraltet ist (aktuell ist 1.4.5).
Hallo
Danke für den Tipp habe da natürlich auch zuerst dran gedacht, nur wurde mir auf der Weboberfläche des Shelly kein Update angeboten.
Jetzt habe ich den Shelly einmal neu gestartet und siehe da ein Update verfügbar.
Leider bleibt die Warnung im log für jeden meiner 4 Shelly 1 ein mal.
2019.01.31 12:48:12 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4684.
2019.01.31 12:48:12 1: stacktrace:
2019.01.31 12:48:12 1: main::__ANON__ called by fhem.pl (4684)
2019.01.31 12:48:12 1: main::readingsBulkUpdateIfChanged called by ./FHEM/36_Shelly.pm (650)
2019.01.31 12:48:12 1: main::Shelly_status called by ./FHEM/36_Shelly.pm (604)
2019.01.31 12:48:12 1: main::__ANON__ called by FHEM/HttpUtils.pm (606)
2019.01.31 12:48:12 1: main::__ANON__ called by fhem.pl (734)
2019.01.31 12:48:12 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4684.
2019.01.31 12:48:12 1: stacktrace:
2019.01.31 12:48:12 1: main::__ANON__ called by fhem.pl (4684)
2019.01.31 12:48:12 1: main::readingsBulkUpdateIfChanged called by ./FHEM/36_Shelly.pm (650)
2019.01.31 12:48:12 1: main::Shelly_status called by ./FHEM/36_Shelly.pm (604)
2019.01.31 12:48:12 1: main::__ANON__ called by FHEM/HttpUtils.pm (606)
2019.01.31 12:48:12 1: main::__ANON__ called by fhem.pl (734)
2019.01.31 12:48:12 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4684.
2019.01.31 12:48:12 1: stacktrace:
2019.01.31 12:48:12 1: main::__ANON__ called by fhem.pl (4684)
2019.01.31 12:48:12 1: main::readingsBulkUpdateIfChanged called by ./FHEM/36_Shelly.pm (650)
2019.01.31 12:48:12 1: main::Shelly_status called by ./FHEM/36_Shelly.pm (604)
2019.01.31 12:48:12 1: main::__ANON__ called by FHEM/HttpUtils.pm (606)
2019.01.31 12:48:12 1: main::__ANON__ called by fhem.pl (734)
2019.01.31 12:48:12 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4684.
2019.01.31 12:48:12 1: stacktrace:
2019.01.31 12:48:12 1: main::__ANON__ called by fhem.pl (4684)
2019.01.31 12:48:12 1: main::readingsBulkUpdateIfChanged called by ./FHEM/36_Shelly.pm (650)
2019.01.31 12:48:12 1: main::Shelly_status called by ./FHEM/36_Shelly.pm (604)
2019.01.31 12:48:12 1: main::__ANON__ called by FHEM/HttpUtils.pm (606)
2019.01.31 12:48:12 1: main::__ANON__ called by fhem.pl (734)
Hier noch einmal ein list vom Shelly
Internals:
CHANGED
DEF 192.168.0.35
DURATION 0
FUUID 5c488521-f33f-e69a-9f66-04417c4d0fd0541d
INTERVAL 60
MOVING stopped
NAME F_Licht_EG
NR 413
STATE off
TCPIP 192.168.0.35:80
TYPE Shelly
READINGS:
2018-12-05 12:02:50 cloud disabled
2018-12-05 13:05:01 config default_state=last
2019-01-31 12:36:27 firmware v1.4.5
2019-01-31 12:45:07 network connected
2019-01-31 08:47:11 relay off
2019-01-31 12:45:12 state off
Attributes:
icon hue_filled_gu10_par16
model shelly1
room Flur
Gruß Alex
@majestro84
Habe ich auch, nur die Zeilennummern sind anders.
2019.02.01 20:13:59 1: stacktrace:
2019.02.01 20:13:59 1: main::__ANON__ called by fhem.pl (4602)
2019.02.01 20:13:59 1: main::readingsBulkUpdateIfChanged called by ./FHEM/36_Shelly.pm (651)
2019.02.01 20:13:59 1: main::Shelly_status called by ./FHEM/36_Shelly.pm (604)
2019.02.01 20:13:59 1: main::__ANON__ called by FHEM/HttpUtils.pm (606)
2019.02.01 20:13:59 1: main::__ANON__ called by fhem.pl (724)
Die Perl Warnung habe ich auch schon lange.
Hallo Zusammen,
ich wollte heute auch einmal das Shelly-Modul in FHEM aktivieren, bekomme aber folgende Fehlermeldung:
2019.02.11 20:06:15 0: Can't locate JSON.pm in @INC (you may need to install the JSON module) (@INC contains: . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/arm-linux-gnueabihf/perl5/5.20 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl ./FHEM) at ./FHEM/36_Shelly.pm line 34.
BEGIN failed--compilation aborted at ./FHEM/36_Shelly.pm line 34.
2019.02.11 20:06:26 1: reload: Error:Modul 36_Shelly deactivated:
Can't locate JSON.pm in @INC (you may need to install the JSON module) (@INC contains: . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/arm-linux-gnueabihf/perl5/5.20 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl ./FHEM) at ./FHEM/36_Shelly.pm line 34.
BEGIN failed--compilation aborted at ./FHEM/36_Shelly.pm line 34.
Ich habe das Modul entsprechend des Shelly WIKI in FHEM konfiguriert und auch ein Update gemacht.
Woran kann dieser Fehler liegen, muss ich irgendetwas nachinstallieren?
Vielen Dank für die Hilfe.
Pit
Steht doch auch im Wiki deutlich hervorgehoben- der Hinweis die commandref zu lesen.
Dort findest Du genau wie auch in Deiner geposteten Fehlermeldung den Hinweis
This module needs the JSON package
Also bitte auf dem Server nachinstallieren
Leider kann man das Shelly modul nicht disablen. Da ich mein WLAN ausschalte, zeigt das modul im state immer error an, wobei dann meine Structure auf undefined geht.
Kann man das disable noch dazubauen? Damit würde der state bei Wlan ausfall dann wohl immer den letzten Zustand beibehalten ...
Zitat von: inoma am 12 Februar 2019, 00:05:39
Leider kann man das Shelly modul nicht disablen. Da ich mein WLAN ausschalte, zeigt das modul im state immer error an, wobei dann meine Structure auf undefined geht.
Kann man das disable noch dazubauen? Damit würde der state bei Wlan ausfall dann wohl immer den letzten Zustand beibehalten ...
ja hatte ich auch. Einfach "interval" auf Null, dann wird nichts gepollt
Hallo Zusammen,
@det, habe ich überlesen, sorry.
Da ich nicht so bewandert bin in Sachen Linux, gibt es eine Info (WIKI?), wie ich das JSON Package im Zusammenhang mit FHEM am besten installiere? Ich habe gelesen, dass es sowohl über CPAN als auch über apt-get geht, was macht hier Sinn und funktioniert?
Vielen Dank und viele Grüße
Pit
https://wiki.fhem.de/wiki/Raspberry_Pi
Hallo,
nachdem ich hier im Forum auf Shelly aufmerksam geworden bin, habe ich letzte Woche 3 Shellys bekommen. Ich nutze ebenfalls das Modul 36_Shelly.
Meine beiden Shelly2 habe ich als Rollladenschalter eingebunden. Die Befehle open und closed funktionieren einwandfrei. Ich habe jedoch 2 Probleme, für die ich keine Lösung finde.
- Wenn ich einen Prozentwert auswähle, erhalte ich als state ERROR. Es wird nicht geschaltet.
Edit:
Wenn ich den Befehl direkt im Browser absetze, erhalte ich als Antwort: Not calibrated!
In der App habe ich nun auch die Kalibrierung gefunden. Allerdings wird die Kalibrierung mit dem Fehler "Calibration failed - maxtime reached on first opening" abgeschlossen.
- Beim Befehl open und closed wird bei state moving_up und moving_down angezeigt. Wenn der Befehl abgearbeitet ist, wird stopped angezeigt. Müsste hier nicht open oder closed angezeigt werden?
Ich vermute, dass ich irgendetwas falsch eingestellt habe, kann aber den Fehler nicht finden.
Shellysettings:
{"device":{"type":"SHSW-21","mac":"B6E62D5A4F70","hostname":"shellyswitch-5A4F70","num_outputs":2, "num_meters":1, "num_rollers":1},"wifi_ap":{"enabled":false,"ssid":"shellyswitch-5A4F70","key":""},"wifi_sta":{"enabled":true,"ssid":"NetzBM_Low","ipv4_method":"static","ip":"192.168.178.60","gw":"192.168.178.1","mask":"255.255.255.0","dns":null},"mqtt": {"enable":false,"server":"192.168.33.3:1883","user":"","reconnect_timeout_max":60.000000,"reconnect_timeout_min":2.000000,"clean_session":true,"keep_alive":60,"will_topic":"shellies/shellyswitch-5A4F70/online","will_message":"false","max_qos":0,"retain":false,"update_period":30},"login":{"enabled":false,"unprotected":false,"username":"admin","password":"admin"},"pin_code":"zjv#Q-","coiot_execute_enable":false,"name":"","fw":"20190213-160238/v1.4.7@62267d06","build_info":{"build_id":"20190213-160238/v1.4.7@62267d06","build_timestamp":"2019-02-13T16:02:38Z","build_version":"1.0"},"cloud":{"enabled":false,"connected":false},"timezone":"Europe/Berlin","lat":50.110901,"lng":8.682130,"tzautodetect":true,"time":"07:56","hwinfo":{"hw_revision":"prod-2018-10c", "batch_id":5},"mode":"roller","max_power":1840,"relays":[{"name":null,"ison":false,"has_timer":false,"overpower":false,"default_state":"off","btn_type":"toggle","btn_reverse":0,"auto_on":0.00,"auto_off":0.00,"schedule":false,"schedule_rules":[],"sun":false,"sun_on_times":"0000000000000000000000000000","sun_off_times":"0000000000000000000000000000"},{"name":null,"ison":false,"has_timer":false,"overpower":false,"default_state":"off","btn_type":"toggle","btn_reverse":0,"auto_on":0.00,"auto_off":0.00,"schedule":false,"schedule_rules":[],"sun":false,"sun_on_times":"0000000000000000000000000000","sun_off_times":"0000000000000000000000000000"}],"rollers":[{"maxtime":22.00,"default_state":"stop","swap":false,"input_mode":"openclose","button_type":"toggle","btn_reverse":0,"state":"stop","power":0.00,"is_valid":true,"safety_switch":false,"schedule":false,"schedule_rules":[],"sun":false,"sun_open_times":"0000000000000000000000000000","sun_close_times":"0000000000000000000000000000","obstacle_mode":"disabled","obstacle_action":"stop","obstacle_power":200,"obstacle_delay":1,"safety_mode":"while_opening","safety_action":"stop","safety_allowed_on_trigger":"none","off_power":2,"positioning":true}],"meters":[{"power":0.00,"is_valid":true,"timestamp":1550130985,"counters":[0.000, 0.000, 0.000],"total":0}]}Fhem:
Internals:
CHANGED
DEF 192.168.178.60
DURATION 0
FUUID 5c62ba24-f33f-144b-05fc-d8ee70fdacd03790
INTERVAL 30
MOVING stopped
NAME SH_Rollo_WC
NR 975
STATE stopped
TARGETPCT 100
TCPIP 192.168.178.60:80
TYPE Shelly
READINGS:
2019-02-14 06:09:00 cloud disabled
2019-02-13 19:10:23 config rc=
2019-02-14 06:07:59 firmware v1.4.7
2019-02-14 07:29:13 last_dir up
2019-02-14 05:45:22 network connected
2019-02-14 07:29:13 pct 102
2019-02-14 07:29:13 position 102
2019-02-14 07:29:13 power 0
2019-02-14 07:29:13 state stopped
2019-02-12 08:14:54 stop_reason normal
Attributes:
cmdIcon Auf:bms_Pfeil_rot Zu:bms_Pfeil_gruen stop:bms_Stop_2
devStateIcon Zu:fts_shutter_100@blue Auf:fts_shutter_10@blue 9\d.*:fts_shutter_10@blue 8\d.*:fts_shutter_20@blue 7\d.*:fts_shutter_30@blue 6\d.*:fts_shutter_40@blue 5\d.*:fts_shutter_50@blue 4\d.*:fts_shutter_60@blue 3\d.*:fts_shutter_70@blue 2\d.*:fts_shutter_80@blue 1\d.*:fts_shutter_90@blue 0\d.*:fts_shutter_100@blue
eventMap open:Auf closed:Zu
group Rollläden
interval 30
mode roller
model shelly2
pct100 open
room Rollläden,Shelly
webCmd Auf:Zu:stop:pct
widgetOverride pct:0,10,20,30,40,50,60,70,80,90,100Log:
2019.02.14 11:19:36 1: [Shelly_updown] Issue a non-blocking call to http://192.168.178.60:80/roller/0?go=to_pos&roller_pos=50
2019.02.14 11:19:36 1: [Shelly_updown] has invalid JSON data
Grüße
Apollon
Unterstützt das Modul schon die neuen Rgbw2 von Shelly?
Ist das eine Antwort auf meine Frage?
So wie ich das sehe, wird RGBW2 lediglich vom Shelly RGBW2 unterstützt. Ich habe aber 2 Shelly2-Geräte.
ZitatUnterstützt das Modul schon die neuen Rgbw2 von Shelly?
Nein, wird aber kommen.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 14 Februar 2019, 17:47:22
Nein, wird aber kommen.
LG
pah
Ok super, meine RGBW2 sind heute angekommen. :D
Hi zusammen,
zunächst einmal vielen Dank an pah für das tolle Modul!
Ich habe ein paar Shelly1 und einen Shelly2, mit dem 2er habe ich einen Doppelschalter ersetzt.
Das mit den Channels funktioniert soweit auch, aber wenn man den Status / das Gerät bspw. via Alexa oder FTUI schalten möchte muss ich da ja eine 1zu1 Beziehung haben, wenn ich nicht auf dem Schlauch stehe.
Wie mache ich das dann am sinnvollsten? Ich hätte dazu 2 Ideen:
1. Ich binde den Shelly 2 mal als eigenes Gerät ein
2. Ich nutze für channel 1 einen Dummy
Oder wie würdet ihr das machen?
Danke, Gruß & noch einen schönen Sonntag,
Tobi
So.
Zitat2. Ich nutze für channel 1 einen Dummy
Oder das Widget leicht modifizieren.
LG
pah
Seit letztem Wochenende funktioniert mein Shelly 2 nicht mehr. Wobei der 1er noch funktioniert.
Ich bekomme folgende Fehlermeldung
2019.02.18 20:22:38 5: [Shelly_status] Issue a non-blocking call to http://192.168.188.101:80/status
2019.02.18 20:22:42 1: [Shelly_status] has error connect to http://192.168.188.101:80 timed out
Wobei der shelly2 über den Browser normal erreichbar ist.
Als Firmware habe ich auf beiden
1.4.7-revertwifi
Die Fehlermeldung ist doch eindeutig.
LG
pah
ich habe auch eine Fehlermeldung, die für mich nicht eindeutig ist:
2019.02.19 18:04:37 1: [Shelly_updown] Issue a non-blocking call to http://<ip>:80/roller/0?go=to_pos&roller_pos=0
2019.02.19 18:04:38 1: [Shelly_meter] Issue a non-blocking call to http://<ip>:80/meter/0
2019.02.19 18:04:38 1: [Shelly_meter] has obtained data {"power":147.08,"is_valid":true,"timestamp":1550599479,"counters":[0.000, 0.000, 0.000],"total":0}
2019.02.19 18:04:38 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/36_Shelly.pm line 984.
Gesteuert wird der shelly über das ASC-Modul.
Zitat von: majestro84 am 31 Januar 2019, 12:52:29
Hallo
Danke für den Tipp habe da natürlich auch zuerst dran gedacht, nur wurde mir auf der Weboberfläche des Shelly kein Update angeboten.
Jetzt habe ich den Shelly einmal neu gestartet und siehe da ein Update verfügbar.
Leider bleibt die Warnung im log für jeden meiner 4 Shelly 1 ein mal.
2019.01.31 12:48:12 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4684.
2019.01.31 12:48:12 1: stacktrace:
2019.01.31 12:48:12 1: main::__ANON__ called by fhem.pl (4684)
2019.01.31 12:48:12 1: main::readingsBulkUpdateIfChanged called by ./FHEM/36_Shelly.pm (650)
2019.01.31 12:48:12 1: main::Shelly_status called by ./FHEM/36_Shelly.pm (604)
2019.01.31 12:48:12 1: main::__ANON__ called by FHEM/HttpUtils.pm (606)
2019.01.31 12:48:12 1: main::__ANON__ called by fhem.pl (734)
2019.01.31 12:48:12 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4684.
2019.01.31 12:48:12 1: stacktrace:
2019.01.31 12:48:12 1: main::__ANON__ called by fhem.pl (4684)
2019.01.31 12:48:12 1: main::readingsBulkUpdateIfChanged called by ./FHEM/36_Shelly.pm (650)
2019.01.31 12:48:12 1: main::Shelly_status called by ./FHEM/36_Shelly.pm (604)
2019.01.31 12:48:12 1: main::__ANON__ called by FHEM/HttpUtils.pm (606)
2019.01.31 12:48:12 1: main::__ANON__ called by fhem.pl (734)
2019.01.31 12:48:12 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4684.
2019.01.31 12:48:12 1: stacktrace:
2019.01.31 12:48:12 1: main::__ANON__ called by fhem.pl (4684)
2019.01.31 12:48:12 1: main::readingsBulkUpdateIfChanged called by ./FHEM/36_Shelly.pm (650)
2019.01.31 12:48:12 1: main::Shelly_status called by ./FHEM/36_Shelly.pm (604)
2019.01.31 12:48:12 1: main::__ANON__ called by FHEM/HttpUtils.pm (606)
2019.01.31 12:48:12 1: main::__ANON__ called by fhem.pl (734)
2019.01.31 12:48:12 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4684.
2019.01.31 12:48:12 1: stacktrace:
2019.01.31 12:48:12 1: main::__ANON__ called by fhem.pl (4684)
2019.01.31 12:48:12 1: main::readingsBulkUpdateIfChanged called by ./FHEM/36_Shelly.pm (650)
2019.01.31 12:48:12 1: main::Shelly_status called by ./FHEM/36_Shelly.pm (604)
2019.01.31 12:48:12 1: main::__ANON__ called by FHEM/HttpUtils.pm (606)
2019.01.31 12:48:12 1: main::__ANON__ called by fhem.pl (734)
Hier noch einmal ein list vom Shelly
Internals:
CHANGED
DEF 192.168.0.35
DURATION 0
FUUID 5c488521-f33f-e69a-9f66-04417c4d0fd0541d
INTERVAL 60
MOVING stopped
NAME F_Licht_EG
NR 413
STATE off
TCPIP 192.168.0.35:80
TYPE Shelly
READINGS:
2018-12-05 12:02:50 cloud disabled
2018-12-05 13:05:01 config default_state=last
2019-01-31 12:36:27 firmware v1.4.5
2019-01-31 12:45:07 network connected
2019-01-31 08:47:11 relay off
2019-01-31 12:45:12 state off
Attributes:
icon hue_filled_gu10_par16
model shelly1
room Flur
Gruß Alex
Hallo
Die Warnung besteht weiterhin gibt es dafür eine Lösung?
Gruß Alex
Ja: FHEM nicht so oft neu starten...
Ernsthaft: Ich habe im Moment zu viel um die Ohren, als dass ich mich um eine triviale Warnungsmeldung beim Systemstart kümmern könnte.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 21 Februar 2019, 12:34:25
Ja: FHEM nicht so oft neu starten...
Ernsthaft: Ich habe im Moment zu viel um die Ohren, als dass ich mich um eine triviale Warnungsmeldung beim Systemstart kümmern könnte.
LG
pah
Guten Morgen
Ich habe nur nachgefragt, da es seit meiner ersten Nachfrage zwei Modul Updates gab, es hätte ja gut sein können das in diesem Bereich was geändert wurde, nur halt ohne Erfolg. ( Ich habe mir jetzt nicht persönlich den Code angeguckt.)
In diesem Sinne Entschuldigung das ich noch einmal gefragt habe. Kann ja keiner riechen das der Modulator im Moment viel um die Ohren hat.
Ich gehe dann mal davon aus das die Warnung ignoriert werden kann und keine weiteren Einflüsse hat auf das laufende System.
Es tritt ja nicht nur bei Systemstart auf sondern bei jeder Abfrage.
Aber gut ich werde die Meldung einfach überlesen.
Gruß Alex
Zitat von: Prof. Dr. Peter Henning am 14 Februar 2019, 17:47:22
Nein, wird aber kommen.
LG
pah
Ist schon bekannt, wann der RGBW2 unterstützt wird?
Klar. Dann, wenn ich Zeit dafür habe.
LG
pah
OK, habe die Erweiterung des Moduls 36_Shelly.pm auf den Shelly RGBW2 begonnen. Wer will freiwillig testen ?
LG
pah
Ich würde gerne testen. :D
Ich auch.
Edit: Hier die zweite Beta-Version, unterstützt auch den White Mode.
LG
pah
Ich habe beide BETA mal eingespielt.
Bei beiden gibt es nur get und kein set.
Bei der ersten wurde die Readings gefühlt alle 30 Sekunden aktualisiert. Geht das auch häufiger? Oder über MQTT aus dem Modul?
Bei der 2. Version bekomme ich keine Verbindung zu dem Gerät, state ist initialized.
Kann ich nicht so ganz glauben - sind die Attribute model und mode gesetzt ?
LG
pah
Mode war es. Mir war noch nicht bekannt, dass man dies in der App umstellen kann.
Bei set NAME rgb kommt nach dem verschieben / klicken eines Reglers der Fehler:
fhemweb_colorpicker.js line 85:
Uncaught TypeError: cmd is not a function
Wieso denn "in der App" ?
ZitatBei set NAME rgb kommt nach dem verschieben / klicken eines Reglers der Fehler:
Ich nehme an: länger kein Update gemacht. Das kommt nämlich nicht aus dem Modul.
LG
pah
In der App kann man White und Color Mode einstellen.
FHEM ist aktuell. Erst habe ich FHEM aktualisiert, dann 36_Shelly.pm eingespielt.
Es soll der Mode aber nicht in der App, sondern im FHEM-Device eingestellt werden !
LG
pah
Zitat von: Prof. Dr. Peter Henning am 23 März 2019, 15:24:13
Edit: Hier die zweite Beta-Version, unterstützt auch den White Mode.
LG
pah
Hallo pah,
ich bekomme demnächst hoffentlich meine ersten Shelly 2.5.
Kannst du bei deiner Überarbeitung für den RGBW2 auch gleich den 2.5 in die Modelliste mit aufnehmen ?
Sowie ich das sehe kann ist der doch von der API nahezu identisch mit dem 2er nur das jetzt 2 getrennte Messungen erfolgen.
Kann man bis dahin nicht einfach alles über Model 2 machen ?
ZitatKann man bis dahin nicht einfach alles über Model 2 machen ?
Nein - zwei Messstellen sind nun einmal etwas Anderes, als eine Messstelle.
Das lässt sich zwar leicht einbauen, kostet aber dennoch etwas Zeit.
LG
pah
Den Mode habe ich im Modul gesetzt.
Gibt es schon was zum fhemweb_colorpicker.js Problem?
ZitatGibt es schon was zum fhemweb_colorpicker.js Problem?
Das ist ein klassisches PAL, ein "Problem Anderer Leute" - nochzumal es sonst nirgendwo auftritt.
Tipp: per widgetoverride ein anderes Widget für rgb auswählen.
LG
pah
Mit widgetOverride rgb:colorpicker,RGB bekomme ich zumindest keinen Fehler mehr.
Wie kann ich die Helligkeit für RGB einstellen? Für weiß gibt es set white X.
ZitatWie kann ich die Helligkeit für RGB einstellen?
Dafür hat es doch das Widget !
pah
Wie kann ich per set Befehl die Helligkeit steuern? Sehe ich den Wert in einem Reading?
Mit dem RGB Widget gibt es nur ein Kästen mit den Farben und eines von weiß bis schwarz. Den Hex Wert kann das Widget ebenfalls nicht auslesen.
Zitatweiß bis schwarz
Sicher nicht.
ZitatDen Hex Wert kann das Widget ebenfalls nicht auslesen
Ich verstehe auch nicht, was damit gemeint ist
pah
So sieht der colorpicker mit widgetOverride: rgb:colorpicker,rgb aus. (colorpicker rgb)
Wen ich set Shelly rgb auswähle, erscheint im Feld dahinter FFFFFF und nicht die aktuelle Farbe. Mit dem Standard Colorpicker werden automatisch die 3 Slider zu der richtigen Position der Farbe verschoben. (colorpicker default)
Pardon, aber das ist einfach Unsinn.
Es gibt keinen "Standard Colorpicker". Es gibt einen RGB colorpicker, und einen HSV colorpicker, und einen Farbtemperatur colorpicker.
Und selbstverständlich ist der korrekte Hexadezimalwert FFFFF, wenn die Helligkeit auf 100% steht und die Farbsättigung Null ist (HSV Farbmodell).
Tipp: Einfach mal schlau machen, wie das HSV Farbmodell funktioniert.
pah
jetzt verstehe ich zumindest HSV mehr. Wenn ist set NAME rgb mache, kommt aber colorpicker für HSV. Das mit den HSV Werten funktioniert auch.
Über die command line set rgb kann aber nur ein rgb Wert gesetzt werden. Mit HSV Werten kommt er dort nicht zurecht.
Es gibt auch nur rgb Readings. Kann ich dort die Dimmstufe sehen?
Es gibt bei mehrfarbigen Leuchten keine "Dimmstufe", weil der Beitrag der drei Farben zum Helligkeitseindruck unterschiedlich ist. Siehe hier, Kapitel 4
https://books.google.de/books/about/Taschenbuch_Multimedia.html?id=Af_8wAEACAAJ&source=kp_cover&redir_esc=y
Wer es benötigt, sollte sich mit Hilfe der Funktion Color::rgb2hsv eine Umrechnung ins HSV-Farbmodell bauen und den dritten Wert anzeigen lassen. Und umgekehrt: Wer seine Leuchte mit hsv einstellen möchte, kann sich mit Color::hsv2rgb die hexadezimalen Werte für das set rgb-Kommando ausrechnen.
pah
Ich finde keine weiteren Infos zu color::rgb2hsv
Ich möchte mir die HSV Werte zunächst in einem userReading anzeigen lassen. Allerdings bekomme ich den Fehler:
Undefined subroutine &Color::rgb2hsv
Mit welchem Format muss ich rgb2hsv aufrufen?
Color::rgb2hsv ($r, $g, $b)
r, g und b sind die RGB Werte bis 255.
::)
https://wiki.fhem.de/wiki/Color
pah
a) Zum Thema "Status bei manuellem Schalten":
Ich habe gerade frisch einen Shelly1 mit Firmware 1.4.8. und mit Modulversion 1.81 im Test. Da ist nichts mit automatischer Meldung nach manuellem Schalten, nur nach Pollen. Habe ich was übersehen? Galt die aktive Meldung wirklich nur für die beta vom Shelly2?
b) ich bekomme frisch nach dem Einrichten mit schöner Regelmäßigkeit jede Minute Fehler ins Log:
2019.03.31 17:34:53.990 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4693.
2019.03.31 17:34:53.990 1: stacktrace:
2019.03.31 17:34:53.991 1: main::__ANON__ called by fhem.pl (4693)
2019.03.31 17:34:53.991 1: main::readingsBulkUpdateIfChanged called by ./FHEM/36_Shelly.pm (650)
2019.03.31 17:34:53.991 1: main::Shelly_status called by ./FHEM/36_Shelly.pm (604)
2019.03.31 17:34:53.991 1: main::__ANON__ called by FHEM/HttpUtils.pm (606)
2019.03.31 17:34:53.991 1: main::__ANON__ called by fhem.pl (739)
Geht auch nach Neustart nicht weg.
c) nur am Rande: wegen a) MQTT zu nutzen wäre für mich keine Hürde, weder mit Shelly-Fw noch mit Tasmota, habe letztere reichlich im Einsatz. Allerdings habe ich gerade festgestellt, dass ein Shelly 1 (erste Version) mit Tasmota 0,3W weniger verbraucht, also 0,4 im Standby und 0,7 Watt mit aktivem Relais. Weniger Watt = weniger warm = weniger Veschleiß, gerade bei beengtem Einbau.
... Ruder zurück, nach letzten Messungen nehmen sich beide doch nicht so viel. Keine Ahnung, heute nachmittag war der Unterschied deutlich sichtbar, ich wechselte zwischen beiden Aktoren.
Tasmota bringt übrigens vom Fleck weg das Eingangs-Schalterverhalten "edge" mit, d.h. jede Schaltzustandsänderung bedeutet auch eine Relais-Änderung.
Da steht zwar was von rgb2hsv nur leider weiß ich immer noch nicht, wie ich die Funktion aufrufe.
@Pfriemler:
ZitatGalt die aktive Meldung wirklich nur für die beta vom Shelly2?
Äh - verstehe ich nicht. Ohne MQTT gibt der Shelly niemals eine aktive Meldung heraus, sondern muss abgefragt werden. Habe ich auch nirgendwo anders geschrieben.
Wer das braucht, wird um MQTT nicht herumkommen. Das Modul 36_Shelly.pm hat also zwei Anwendungsbereiche:
1. Schnell und ohne großen Aufwand (also auch geeignet für Einsteiger) Ergebnisse mit Shelly-Aktoren zu erzielen
2. Anwendungsfälle, in denen die Meldung eines manuellen Schaltvorgangs an FHEM bis zum nächsten Polling warten kann oder ganz und gar unnötig ist.
Zu den letztgenannten Fällen gehören insbesondere die, bei denen ein Shelly direkt in eine Leuchte eingebaut wird. Oder z.B. der Einbau in einem Rollladentaster.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 01 April 2019, 11:17:59
@Pfriemler: Äh - verstehe ich nicht. Ohne MQTT gibt der Shelly niemals eine aktive Meldung heraus, sondern muss abgefragt werden. Habe ich auch nirgendwo anders geschrieben.
Äh ... im Wiki steht das so ... (nachforsch) ... aber nicht von Dir, sondern von "drhirn" im Wiki in der Version vom 5.3.2019 bis heute. Punkt für Dich.
So brauche ich also MQTT, weil ich auf das manuelle Betätigen des Lichts zeitnah reagieren möchte. Dann wissen wir das.
Dann hat sich die Frage zu den Fehlern im Log für mich erledigt - wenn das nicht ein auch andere User betreffendes Problem ist...
"drhirn", soso.
Herr, lass Hirn vom Himmel fallen...
LG
pah
Zitat von: bombardi am 26 März 2019, 12:43:09
Hallo pah,
ich bekomme demnächst hoffentlich meine ersten Shelly 2.5.
Kannst du bei deiner Überarbeitung für den RGBW2 auch gleich den 2.5 in die Modelliste mit aufnehmen ?
Sowie ich das sehe kann ist der doch von der API nahezu identisch mit dem 2er nur das jetzt 2 getrennte Messungen erfolgen.
Kann man bis dahin nicht einfach alles über Model 2 machen ?
Ich habe jetzt eine Bestätigung von Shelly
HTTP API Documentation is same.
This is just the upgraded product.
Kind Regards,
Miroslav Grozdanov
Account & Support Manager
Allterco Robotics
Bekomme ich beim RGB2 heraus ob das RGB Band leuchtet? Bei weiß kann man es an L-white = 0 erkennen.
Guten Abend,
das Shelly BETA Modul habe ich für zwei RGBW2 Aktoren im White-Modus eingebunden.
Ich kann soweit keine Fehler feststellen, nur ich habe nach einigem Ausprobieren immer noch das Problem, mehr als einen Channel pro Aktor gleichzeitig anzusprechen.
Um Hilfe / Tip wäre ich dankbar.
Vielen Dank!
Was ist denn mit "Ansprechen" gemeint? Wenn das bedeuten soll, alle Kanäle gleichzeitig auf einen bestimmten Wert zu dimmen: Das geht nicht, ist im API von Shelly nicht vorgesehen.
Ich habe festgestellt, dass ich im White-Mode bei der Eingabe die beiden Parameter für den Prozentwert und den Kanal vertauscht habe. Ist in der angefügten Datei korrigiert.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 01 April 2019, 22:19:57
"drhirn", soso.
Herr, lass Hirn vom Himmel fallen...
LG
pah
Umsonst versucht, mich zu beleidigen. Das ist meine Änderung (https://wiki.fhem.de/w/index.php?title=Shelly-Aktoren&diff=prev&oldid=29782) im Wiki, nicht die, die Pfriemler angesprochen hat. ;)
Verd.. t, hab ich mich so verguckt? Sorry. Mir ging es ja nur um eine Bestätigung dass das nicht von pah war.
Ich muss das mit dem Versionsvergleich wohl noch mal üben...
Hallo zusammen,
seit der FW 1.49 wird auch ein toggle nativ unterstützt.
Ist es möglich dies auch direkt vom Modul auszulösen? Kann ich das selber anpassen oder muss das im Modul angepasst werden?
Danke und Gruß
Mathias
Zitat von: Prof. Dr. Peter Henning am 17 April 2019, 05:07:27
Was ist denn mit "Ansprechen" gemeint? Wenn das bedeuten soll, alle Kanäle gleichzeitig auf einen bestimmten Wert zu dimmen: Das geht nicht, ist im API von Shelly nicht vorgesehen.
Ich habe festgestellt, dass ich im White-Mode bei der Eingabe die beiden Parameter für den Prozentwert und den Kanal vertauscht habe. Ist in der angefügten Datei korrigiert.
LG
pah
Danke für die Korrektur.
Mit "Ansprechen" meinte ich das gleichzeitige Dimmen von mehr wie einem Kanal gleichzeitig sowie ein on / off auf mehreren Kanälen gleichzeitig.
Nachdem das Dimmen durch die API nicht unterstützt wird, gehe ich davon aus, das das gleichzeitige Schalten der Kanäle auch nicht vorgesehen ist.
Was mich nur in diesem Zusammenhang verwundert, ist die Tatsache, dass ein sequenzielles Schalten auch nicht funktioniert.
Benötigt der RGBW2 Aktor eventuell eine Pause zwischen den einzelnen Befehlen? Ich vermute das weil:
set rgbw2Aktor on 0;set rgbw2Aktor on 1 Auszug aus einer If-Anweisung:
{fhem("set rgbw2Aktor on 0;;set rgbw2Aktor on 1")}funktioniert nicht. Das erste set wird immer ausgeführt, dass zweite nie.
Wenn ich ein sleep 1 einfüge wie folgt, werden die Kanäle geschalten:
set rgbw2Aktor on 0;sleep 1;set rgbw2Aktor on 1 Einen Fehler in meiner Syntax möchte ich natürlich nicht ausschließen.
ZitatBenötigt der RGBW2 Aktor eventuell eine Pause zwischen den einzelnen Befehlen?
Klar, denn das ist jeweils http request und response. Wobei ich nicht weiß, wie lange die minimale Pause sein muss, das sollte man einmal austesten.
LG
pah
(https://uploads.tapatalk-cdn.com/20190421/a4226e36a7a584478209f7c4c95472d5.jpg)
Das ist doch mal eine super Neuigkeit - damit wird ja das Pollen nahezu unnötig und eine Schaltaktion wird wie bei MQTT direkt übermittelt, ist aber mit wesendlich weniger Overhat realisierbar.
@pah: wusstest du bereits davon und planst du dies einzubauen?
Gesendet von iPhone XR mit Tapatalk
Sagen wir: Ich hatte so eine Ahnung. Und es wird eingebaut, sobald es verfügbar ist ...
LG
pah
Super! [emoji1360]
Gesendet von iPhone XR mit Tapatalk
Zitat von: Prof. Dr. Peter Henning am 17 April 2019, 05:07:27
[...]
Ist in der angefügten Datei korrigiert.
[...]
Hallo,
ich verwende das Modul aus der angehängten Datei mit einem Shelly RGBW2. Ich habe vier weiße Streifen am Shelly. Im Logfile finde ich bei jedem Schaltvorgang diese Art Meldungen:
2019.04.25 21:13:20 1: [Shelly_dim] returns without success, desired brightness ?turn=on, but measured brightness=80
2019.04.25 21:13:22 1: [Shelly_dim] returns without success, desired brightness ?turn=on, but measured brightness=80
2019.04.25 21:13:23 1: [Shelly_dim] returns without success, desired brightness ?turn=on, but measured brightness=80
2019.04.25 21:13:25 1: [Shelly_dim] returns without success, desired brightness ?turn=on, but measured brightness=80
2019.04.25 21:15:16 1: [Shelly_dim] returns without success, desired brightness ?turn=on, but measured brightness=80
2019.04.26 06:05:52 1: [Shelly_dim] returns without success, desired brightness ?turn=off, but measured brightness=80
2019.04.26 06:05:54 1: [Shelly_dim] returns without success, desired brightness ?turn=off, but measured brightness=80
2019.04.26 06:05:56 1: [Shelly_dim] returns without success, desired brightness ?turn=off, but measured brightness=80
2019.04.26 06:05:58 1: [Shelly_dim] returns without success, desired brightness ?turn=off, but measured brightness=80
Liegt wohl an dieser Zeile im Modul:
$ grep -nB3 "desired" 36_Shelly.pm
1002- $cmd =~ s/\?brightness=//;
1003-
1004- if( $bright ne $cmd ) {
1005: Log3 $name,1,"[Shelly_dim] returns without success, desired brightness $cmd, but measured brightness=$bright";
Als Kommando sende ich im Abstand von 2s ein "set shelly on #" für jeden Kanal (trotzdem sind ab und an nicht alle Streifen an). Die Helligkeit habe ich einmal über set shelly pct 80 # auf 80% für alle Kanäle gestellt.
Gruß und vielen Dank für das Modul
Kann ignoriert werden, ist im nächsten Release gefixt.
LG
pah
wünsche einen schönen Sonntag,
verbunden mit einer Frage: mein Shelly RGBW Device heist als Alexa name FARBE - wenn ich sage Alexa stelle FARBE auf weiß - stellt sich der Farbton nachvollziehbar auf rot. Blau, gelb und grün geht. Liegt es an der falschen Ansprache? Geht das hier bei jemanden, oder soll ich die Frage im Alexa Forumbereich stellen? Da das Device im Badezimmer installiert ist, wäre mir eine funktionierende Sprachsteuerung schon wichtig. Hänge zur Vollständigkeit mal das Log an, was Alexa bei dem Versuch weiß einzustellen verstanden hat.
Hallo
Ich habe mir einige Shelly1pm gekauft.
Scheinbar werden die leider noch nicht voll unterstützt. :-(
Wenn ich das attr model nicht setzte kann ich sie nicht schalten aber das Reading Power wird angezeigt.
list
Internals:
CFGFN
DEF 192.168.6.146
DURATION 0
FUUID 5cc590d1-f33f-a5a6-54e9-4e562db7717387af
INTERVAL 60
MOVING stopped
NAME OG1_SZ_Steckdose
NR 1897
STATE OK
TCPIP 192.168.6.146:80
TYPE Shelly
Helper:
DBLOG:
network:
mylogdb:
TIME 1556451537.64286
VALUE connected
state:
mylogdb:
TIME 1556451537.64286
VALUE initialized
READINGS:
2019-04-28 13:38:57 cloud disabled
2019-04-28 13:38:57 firmware v1.4.9-switch1pm-hotfix4
2019-04-28 13:38:57 network connected
2019-04-28 13:38:57 overpower_0 0
2019-04-28 13:38:57 power 4.85
2019-04-28 13:38:57 relay_0 on
2019-04-28 13:38:57 state OK
Attributes:
Sobald ich das attr model auf shelly1 setze kann ich sie zwar schalten aber das Reading Power fehlt. :-(
list:Internals:
CFGFN
DEF 192.168.6.146
DURATION 0
FUUID 5cc590d1-f33f-a5a6-54e9-4e562db7717387af
INTERVAL 300
MOVING stopped
NAME OG1_SZ_Steckdose
NR 1897
STATE OK
TCPIP 192.168.6.146:80
TYPE Shelly
Helper:
DBLOG:
network:
mylogdb:
TIME 1556451537.64286
VALUE connected
state:
mylogdb:
TIME 1556451537.64286
VALUE initialized
OLDREADINGS:
READINGS:
2019-04-28 13:38:57 cloud disabled
2019-04-28 13:38:57 firmware v1.4.9-switch1pm-hotfix4
2019-04-28 13:38:57 network connected
2019-04-28 13:38:57 relay_0 on
2019-04-28 13:38:57 state OK
Attributes:
interval 300
model shelly1
room Obergeschoss 1->Schlafzimmer
Ich hoffe das das Model Shelly1pm nachgepflegt wird.
Gruß
Daniel
@det.:
Kannst Du lesen hier:
Zitat[2019-4-28 09:08:44] [FHEM] Shelly_RGBW_Bad: executing set cmd for Hue with value 0
2019-04-28 09:08:44 caching: Shelly_RGBW_Bad-rgb: ff0000
[2019-4-28 09:08:44] [FHEM] value converted to ff0000
[2019-4-28 09:08:44] [FHEM] executing: http://127.0.0.1:8083/fhem?cmd=set%20Shelly_RGBW_Bad%20rgb%20ff0000&fwcsrf=csrf_107685648183428&XHR=1
[2019-4-28 09:08:44] [FHEM] Shelly_RGBW_Bad: executing set cmd for Saturation with value 0
2019-04-28 09:08:44 caching: Shelly_RGBW_Bad-rgb: ffffff
[2019-4-28 09:08:44] [FHEM] value converted to ffffff
[2019-4-28 09:08:44] [FHEM] executing: http://127.0.0.1:8083/fhem?cmd=set%20Shelly_RGBW_Bad%20rgb%20ffffff&fwcsrf=csrf_107685648183428&XHR=1
[2019-4-28 09:08:44] [FHEM] Shelly_RGBW_Bad: executing set cmd for Brightness with value 100
[2019-4-28 09:08:44] [FHEM] converted value is unchanged
[2019-4-28 09:08:44] <<<< [ssh] {"context":{"properties":
Alexa-FHEM interpretiert "weiß" zunächst als Hue 0 = Rot und stellt den RGB-Wert auf ff0000. Setzt danach aber die Sättigung auf 0, so dass der neu berechnete RGB-Wert ffffff ist - soweit korrekt. Das zweite Kommando wird aber unmittelbar nach dem ersten abgeschickt, und die Shellys sind nun einmal nicht die schnellsten. Mit anderen Worten: Das zweite REST-Kommando wird gar nicht angenommen.
Hier müsste der Autor des Alexa-Backends nachbessern, und einfach das erste Kommando rauswerfen. Und eben den RGB-Wert gleich auf ffffff setzen
LG
pah
ZitatIch hoffe das das Model Shelly1pm nachgepflegt wird.
Wie heißt gleich das Zauberwort?
LG
pah
@pah,
Vielen Dank, ich werde das dann mal in dem Alexa Bereich anfragen und zum letzten Beitrag - ich habe auch 2 Shelly 1pm und sage dann mal stellvertretend bitte gelegentlich einbauen, auch wenn mir der Energieverbrauch an meiner Einsatzstelle der Dinger ziemlich egal ist.
Hat ein gewisser Herr "F..." seinen geistreichen Beitrag von 17:07 wieder gelöscht oder warum taucht der hier nicht auf? Über seine eigene Dummheit gestolpert?
@UweH: Wird wohl - ich habe nichts gesehen...
@det: Sehn wir mal - immer etwas trickreich, Module für Hardware zu entwickeln, die man selbst nicht hat.
LG
pah
Hier...
Ach, na ja, der war wenigstens noch witzig - da habe ich schon ganz andere Figuren gehört...
LG
pah
Zitat von: WhyTea am 28 April 2019, 13:41:35
Hallo
Ich habe mir einige Shelly1pm gekauft.
Scheinbar werden die leider noch nicht voll unterstützt. :-(
Wenn ich das attr model nicht setzte kann ich sie nicht schalten aber das Reading Power wird angezeigt.
list
Internals:
CFGFN
DEF 192.168.6.146
DURATION 0
FUUID 5cc590d1-f33f-a5a6-54e9-4e562db7717387af
INTERVAL 60
MOVING stopped
NAME OG1_SZ_Steckdose
NR 1897
STATE OK
TCPIP 192.168.6.146:80
TYPE Shelly
Helper:
DBLOG:
network:
mylogdb:
TIME 1556451537.64286
VALUE connected
state:
mylogdb:
TIME 1556451537.64286
VALUE initialized
READINGS:
2019-04-28 13:38:57 cloud disabled
2019-04-28 13:38:57 firmware v1.4.9-switch1pm-hotfix4
2019-04-28 13:38:57 network connected
2019-04-28 13:38:57 overpower_0 0
2019-04-28 13:38:57 power 4.85
2019-04-28 13:38:57 relay_0 on
2019-04-28 13:38:57 state OK
Attributes:
Sobald ich das attr model auf shelly1 setze kann ich sie zwar schalten aber das Reading Power fehlt. :-(
list:Internals:
CFGFN
DEF 192.168.6.146
DURATION 0
FUUID 5cc590d1-f33f-a5a6-54e9-4e562db7717387af
INTERVAL 300
MOVING stopped
NAME OG1_SZ_Steckdose
NR 1897
STATE OK
TCPIP 192.168.6.146:80
TYPE Shelly
Helper:
DBLOG:
network:
mylogdb:
TIME 1556451537.64286
VALUE connected
state:
mylogdb:
TIME 1556451537.64286
VALUE initialized
OLDREADINGS:
READINGS:
2019-04-28 13:38:57 cloud disabled
2019-04-28 13:38:57 firmware v1.4.9-switch1pm-hotfix4
2019-04-28 13:38:57 network connected
2019-04-28 13:38:57 relay_0 on
2019-04-28 13:38:57 state OK
Attributes:
interval 300
model shelly1
room Obergeschoss 1->Schlafzimmer
Ich hoffe das das Model Shelly1pm nachgepflegt wird.
Gruß
Daniel
https://forum.fhem.de/index.php/topic,94060.msg934240.html#msg934240
Bin gerade dran. An sich wird alles unterstützt, man muss sich nur die Mühe machen und es einbauen bzw. nachvollziehen...
ZitatBin gerade dran
An 36_Shelly.pm ????
LG
pah
Nein! Habe auch gesehen, das ich wohl ein wenig durcheinander gekommen bin.
Mein Beitrag bezog sich auf ein Template für MQTT2. Nutze das Modul hier nicht aber ich denke, es kann ja shelly1 einfach erweitert werden. Braucht ihr ggf. Readings/Infos, die ich trotz meines nicht benutzen dieses Moduls, beisteuern kann? Ein Template für MQTT ist so gut wie fertig und Beta-User weiß bescheid. Es geht nur noch um Kleinigkeiten.
@pah, det.: alexa 'spricht' hsv. mir ist zumindest auf den ersten blick nicht ganz klar wo und warum da rgb ins spiel kommt. im alexa-fhem log sollte zu sehen sein welches event von amazon kommt und welche FHEM kommandos dann ausgelöst werden.
Der Knackpunkt ist, dass Alexa-Fhem hier _zwei_ FHEM-Kommandos auslöst, und zwar kurz nacheinander. Zuerst wird der RGB-Wert auf Hue=0°=360°=ff gesetzt, also rgb=ff0000. Und dann kurz danach rgb=ffffff. Und weil das so schnell danach kommt, wird das 2. Kommando eben ignoriert.
Aus meiner Sicht ist das wirklich ein Fehler in Alexa-Fhem, es sollte einfach das erste Kommando entfallen. Wobei ich natürlich nicht ausschließen kann, dass dies schon falsch von Amazon kommt - dann müsste man es irgendwie abfangen.
LG
pah
Hi pah, hi det.,
ich möchte mich mal wieder etwas Warmlaufen, nachdem justme nun länger alleine supported hat. Ich hatte mir den ShellyBulb gekauft, und mit MQTT2_SERVER zum Laufen gebracht. Inzwischen geht das auch über 39_Shelly?
Alexa liefert einen HSV-Vektor. Das Ganze ist obendrein hässlich, weil es in der Doku zudem heißt:
ZitatImportant: The brightness value of a SetColor directive will align to the customer's requested color, however, for the best customer experience when you make a color change, you should maintain the current brightness setting of the target endpoint. For example, if a bulb is set to white at 50% brightness (0.5), and a customer requests a color change to red, the SetColor directive provides hue, saturation and brightness values of 0,1,1, respectively, which indicates full brightness. In this case, you should ignore the brightness value in the directive, and maintain the current brightness setting of 0.5.
Aber das sind ja Luxusprobleme.
MQTT2_SERVER verliert keine Befehle, also "rot" auf "weiß" klappt mit meinem Shellybulb, aber auch hier werden zwei rgb-Werte nacheinander gesetzt. Und wenn ich die Helligkeit über "Schalte <Licht> auf 80%" ändere, geht mein Weiß auch in ein Rot über.
Lange Rede, kurze Frage: Wird 39_Shelly in Sachen HSV auch korrekt ausschließlich über das Setzen von "rgb" angesprochen? Oder welche Settings werden hier exponiert? Falls ja, dann kann ich mich an beiden Problemchen zugleich versuchen.
Ich habe keine Probleme damit, dem Shelly-Modul auch ein "set hsv ..." beizubringen. Die meisten Systeme verwenden dazu zwar eine inkorrekte Umrechnungsfunktion (die richtige kann man in einem meiner Bücher nachlesen...), das ist aber eher unwesentlich.
Die Frage ist nur, ob Alexa-Fhem beim Setzen eines HSV-Wertes tatsächlich nur EINEN Fhem-Befehl abliefert, das muss vorher geklärt werden.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 28 April 2019, 16:56:08
Wie heißt gleich das Zauberwort?
LG
pah
Ui, das Zauberwort? ???
Ah ich weis! Supercalifragilisticexpialigetisch ;D
Spaß beiseite. Natürlich war mein Post als
Bitte gemeint auch wenn ich lediglich von hoffen schrieb.
> Die Frage ist nur, ob Alexa-Fhem beim Setzen eines HSV-Wertes tatsächlich nur EINEN Fhem-Befehl abliefert, das muss vorher geklärt werden.
Nein. Z.Zt. kommen tatsächlich bis zu 3 verschiedene Aufrufe, die sich alle auf den RGB-Wert beziehen. Du hast Recht, dass das unschön ist, und da will ich ran. Wir haben aber diverse Layer:
- Echo-API: HSV-Wert. Weiß erkennt man an S=0. Außerdem mit der Hässlichkeit, dass man "Brightness" bei Erkennen eines Farbwechsels ignorieren und aus der Historie übernehmen soll. Alternativ kommt ein "SetBrightness"-Befehl bei "Schalte Licht auf 40%" rein. Wir sind uns wohl einig: So einen Mist sollte, wenn, dann alexa-fhem ausbügeln
- FHEM-API 1 und 2: 1) ist mod_shelly, 2) ist MQTT_SERVER. Das sollte möglichst gleich sein. Praktischerweise habe ich die Discovery für den ShellyBulb bei MQTT_SERVER implementiert, daher holen mich die eigenen Verbrechen jetzt wieder ein. Unten ein Device-List für meinen ShellyBulb über MQTT_SERVER. Mit der Zielsetzung, dass die FHEM-API gleich sein sollte, egal ob 39_Shelly oder MQTT_SERVER, wäre mir jetzt ein HSV in 39_Shelly nicht lieb.
- Die Shelly-API. Sie hat zwei Eigenarten: Die beiden Modi "white/color" und die Tatsache, dass im Color-Modus mindestens noch "gain" für die Helligkeit gesetzt werden muss. Das gibt meine Implementierung schon mal nicht her - die setzt nur "rgb" - obwohl das API auch noch white und gain hergibt und zumindest ohne gain nicht "richtig" arbeitet.
Das Pferdchen muss also für "sauber" von unten definiert werden, hier: Der Shelly-API. Deswegen hätte ich gerne ein "list device" über 39_Shelly.
Hier der Bulb über MQTT_SERVER:
Internals:
CID shellybulb_3CC533
DEF shellybulb_3CC533
DEVICETOPIC MQTT2_shellybulb_3CC533
FUUID 5c4d5eff-f33f-8d06-27e7-a9681ec2a8b57c90
IODev MQTT2_FHEM_Server
LASTInputDev MQTT2_FHEM_Server
MQTT2_FHEM_Server_MSGCNT 81
MQTT2_FHEM_Server_TIME 2019-05-02 00:27:12
MSGCNT 81
NAME MQTT2_shellybulb_3CC533
NR 211
STATE off
TYPE MQTT2_DEVICE
READINGS:
2018-12-16 12:52:56 blue 0
2018-12-16 12:52:56 brightness 10
2018-12-16 12:52:56 effect 0
2018-12-16 12:52:56 gain 26
2018-12-16 12:52:56 green 0
2018-12-16 12:52:56 ison true
2018-12-16 12:52:56 mode white
2018-12-16 12:52:56 red 128
2019-05-02 00:27:12 rgb 800000
2019-05-02 00:27:12 shellies/shellybulb-3CC533/color/0 off
2019-05-02 00:27:12 state off
2019-05-02 00:27:12 status_blue 125
2019-05-02 00:27:12 status_brightness 51
2019-05-02 00:27:12 status_effect 0
2019-05-02 00:27:12 status_gain 26
2019-05-02 00:27:12 status_green 128
2019-05-02 00:27:12 status_ison false
2019-05-02 00:27:12 status_mode white
2019-05-02 00:27:12 status_red 128
2019-05-02 00:27:12 status_temp 4750
2019-05-02 00:27:12 status_white 0
2018-12-16 12:52:56 temp 3890
2018-12-16 12:52:56 white 0
Attributes:
IODev MQTT2_FHEM_Server
alexaName Licht Kinderzimmer
genericDeviceType light
icon light_control
readingList shellybulb_3CC533:shellies/shellybulb-3CC533/color/0:.* shellies/shellybulb-3CC533/color/0
shellybulb_3CC533:shellies/shellybulb-3CC533/color/0/status:.* { json2nameValue($EVENT, 'status_') }
room MQTT2_DEVICE
setList off:noArg shellies/shellybulb-3CC533/color/0/command off
on:noArg shellies/shellybulb-3CC533/color/0/command on
brightness:colorpicker,BRI,0,1,100 shellies/shellybulb-3CC533/color/0/set {"ison":"true","mode":"white","$EVTPART0":"$EVTPART1"}
temp:colorpicker,CT,3000,10,6500 shellies/shellybulb-3CC533/color/0/set {"ison":"true","mode":"white","$EVTPART0":"$EVTPART1"}
rgb:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/; "shellies/shellybulb-3CC533/color/0/set {\"ison\":true,\"mode\":\"color\",\"red\":".hex($1).",\"green\":".hex($2)."\"blue\":".hex($3) }
userReadings rgb {sprintf("%02X%02X%02X", ReadingsVal($name,"red",99), ReadingsVal($name,"green",99), ReadingsVal($name,"blue",99))}
webCmd on:off:brightness:temp:rgb
@pah: alexa sendet alle drei komponenten in einem event. das lässt sich also als ein kommando an FHEM durchreichen.
homekit sendet leider drei unabhängige events. die idee wäre hier nach dem ersten event ein paar ms zu warten und alles
was danach kommt zu einem set zusammen zu fassen.
ich würde ein set <name> hsv <hue> <saturation> <brighness> als standart vorschlagen. mit hue 0..359, saturation und brighness 0..100.
das würde ich so auch für hue devices nachziehen.
technisch müssen wir dann bei alexa-fhem und homebridge-fhem noch eine HSV characteristic einbauen die alexa direkt verwenden kann und homebridge intern auf Hue, Saturation und Brighness mapped. das warten auf folgende events ist aus anderem Grund zum teil schon implementiert. sollte also auch kein problem sein.
damit sollte das problem aus anwender sicht für zu lösen sein.
für die farbtemperatur muss intern berücksichtig werden sowohl die sprach/app seite als auch das fhem device jeweils entweder mit einer farbtemperatur in kelvin/mired als auch mit einem angenäherten RGB wert arbeiten können. es gibt also 4 Kombinationen zu berücksichtigen. das sollt aber so weit fast alles da sein.
Zitatich würde ein set <name> hsv <hue> <saturation> <brighness> als standart vorschlagen. mit hue 0..359, saturation und brighness 0..100.
Du bist auf dem FHEM-API-Layer. Was sollte denn dann FHEM im Fall ShellyBulb des tun? Bei "S=0" in den Weißmodus wechseln, sonst in den Farbmodus? Die Shellys sind wirklich fies universell, da sie die beiden Modi haben. Perfekterweise müsste Alexa-seitig auch das ColorTemperatureController-Interface rausgereicht werden, also die Weißtemperatur.
Zitat von: gvzdus am 02 Mai 2019, 12:05:17
Hier der Bulb über MQTT_SERVER:
[Sorry für OT hier]
Nur für den Fall, dass das eine Art Referenz sein soll: Das MQTT2-Device sieht aus meiner Warte sehr komisch aus und sollte nach dem aktuellen Standard (nach einem autocreate oder auch der Anwendung eines attrTemplate) anders aussehen.
Wenn Änderungsbedarf an einem attrTemplate bestehen sollte, um da was zu standardisieren, bitte um entsprechende Rückmeldung hier (https://forum.fhem.de/index.php/topic,94060.0.html)!
@gzvdus: ja. farbtemperatur sollte alexa seitige über ColorTemperatureControler gehen.
sonst bietet alexa das weder in der app noch per sprache an.
,nur' weiß kommt je nach gemeldeten fähigkeiten als color oder als color temperature event.
je nach fhem device und mapping hat man dann die 4 möglichen kombinationen von oben.
@pah:
Eingesetztes Modul: 2.0beta3 vom 17.04.
Damit kriege ich meinen ShellyBulb nicht wirklich mit 36_Shelly zum Laufen. Ich verstehe den Code aber nicht:
In Zeile 775
my $mode = AttrVal($name,"mode","relay");
wird $mode aus den FHEM-Attributen geholt. In Zeile 874 und 892 scheinst Du $mode aber als Wert der JSON-Antwort zu verstehen.
Hier meine JSON-Antwort:
2019.05.02 13:37:24 5: [Shelly_status] Issue a non-blocking call to http://192.168.0.5:80/status
2019.05.02 13:37:24 5: [Shelly_status] has obtained data {"wifi_sta":{"connected":true,"ssid":"SBSTR10","ip":"192.168.0.5","rssi":-77},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":true},"time":"13:37","serial":1,"has_update":false,"mac":"DE4F223CC533","lights":[{"ison":true,"mode":"color","red":0,"green":0,"blue":255,"white":0,"gain":44,"temp":4750,"brightness":53,"effect":0}],"meters":[{"power":0.00,"is_valid":"true"}],"update":{"status":"idle","has_update":false,"new_version":"20190402-134156/v1.4.9@9be72c7e","old_version":"20190402-134156/v1.4.9@9be72c7e"},"ram_total":51144,"ram_free":40348,"fs_size":233681,"fs_free":173190,"uptime":3090}
Wir müssen mit der Semantik etwas aufpassen: Im HSV Farbmodell muss strikt von "value" gesprochen werden, nicht einfach von "brightness". Denn das HSB-Farbmodell ist wiederum etwas Anderes.
Zitat$mode aber als Wert der JSON-Antwort
Nein - diesen Wert aus dem JSON verwendet der Code an keiner Stelle.
ZitatDamit kriege ich meinen ShellyBulb nicht wirklich mit 36_Shelly zum Laufen
Wundert mich nicht, schließlich steht nirgendwo, dass der problemlos unterstützt wird. Allerdings enthält der Post keinen Hinweis darauf, was denn nun nicht läuft - das wäre schon sehr hilfreich, um Code für Hardware zu entwickeln, die man selbst nicht verwendet.
LG
pah
Frage ist eigentlich nur: Ist der Code vom 17.04.19 mit "version = 2.0beta3" aktuell? Dann versuche ich, den Bulb da reinzubringen.
Zu der Sache mit "mode":
Die Zeilen:
}elsif( $model eq "shellyrgbw" && $mode eq "white" ){
...
}elsif( $model eq "shellyrgbw" && $mode eq "color" ){
...
wirken halt so, als sollte hier das Attribut mode ("white"/"color") des Shelly-Gerätes interpretiert werden. $mode ist aber nach meinen (mittelmäßigen) Perl-Kenntnissen hier nicht aus der JSON-Antwort ausgelesen.
Nein, der Code ist nicht aktuell - und der Einzige, der Code in meine Module einbaut, bin ich.
LG
pah
Sorry, natürlich kann ich meine schmutzigen Finger vom Code lassen. Nur kurz zum Verständnis: Ich bin hier im Thread, um die Sache mit Alexa geradezuziehen. Deswegen habe ich den Thread rückwärtsgeblättert und die letzte Beta-Version von 36_Shelly gesucht. Da kam ich beim 17.04. raus. Was übersehen? Welche Version sollte ich verwenden?
Teil B) Ich bin zu wenig Theoretiker, um Hardware zu unterstützen, die ich nicht kenne. Deswegen möchte ich das Gerät, was ich habe, den ShellyBulb, möglichst nicht nur über MQTT, sondern auch über 36_Shelly zum Fliegen bringen - in der Hoffnung, dann die 2 x 2 Matrix (MQTT versus 36_Shelly und ShellyBulb versus Shelly RGBW2) auf eine identische Art mit Alexa zum Laufen zu bringen.
Ist doch nicht so ganz destruktiv, der Ansatz, oder?
Hallo Zusammen,
erst einmal vielen Dank für das Modul.
Ich habe zwei Shellys im Test (als Rolloschalter konfiguriert), klappen eigentlich prima.
Nach einigen Wochen hat ein Shelly sich irgendwie aus dem Netzwerk verabschiedet, den musste ich dann resetten (und wieder die feste IP eingestellt), jetzt ist er wieder über das Netzwerk erreichbar, aber in FHEM steht noch immer "not connected".
Muss ich diesen Shelly in FHEM löschen und erneut anlegen oder gibt es da eine einfachere Methode (sowas wie re-connect, wobei das Löschen und anlegen auch nicht so aufwendig ist). Recherche und probieren hat leider keine Info dazu gebracht.
Vielen Dank für die Hilfe.
VG
Pit
Hallo pah,
ich habe seit dem 17.4.19 keine neuen 36_shelly.pm mehr gefunden.
Gibt es noch irgendein Update oder ist der RGBW2 jetzt auch im offiziellen FHEM Update mit drin ?
Was muss ich eigentlich machen wenn ich deine Version statt der offiziellen Version verwenden will
und wie komme ich dann wieder auf den offiziellen Stand zurück ?
Ist bestimmt alles irgendwo beschrieben, aber gefunden habe ich es nicht.
Danke im voraus.
RGBW ist nur im Beta drin.
Ich warte mit einem ordentlichen Release noch auf die Firmware 1.5, mit aktiver Rückmeldung durch den Shelly (Polling entfällt dann !).
Außerdem sind vier Shellyplugs endlich auf dem Weg zu mir, die müssen in das Release auch mit rein.
Und schließlich besteht noch der Wunsch, den Shelly 1PM richtig auszulesen.
Einfach die Datei herunterladen, in das Verzeichnis /opt/fhem/FHEM kopieren und durch attr global exclude_from_update 36_Shelly.pm eine Zeitlang vor dem Überschreiben durch Updates schützen.
LG
pah
Rechte und user vorher korrigieren nicht vergessen! [emoji1375]
Gesendet von iPhone XR mit Tapatalk
Zitat von: Prof. Dr. Peter Henning am 07 Mai 2019, 17:00:42
Außerdem sind vier Shellyplugs endlich auf dem Weg zu mir, die müssen in das Release auch mit rein.
schon verschickt?? ich konnte gestern erst welche ordern :(
mal sehen wann die ankommen....
Hallo PAH,
meine ShellyPlug sind endlich angekommen, nachdem ich schon ein Shelly2 längere Zeit habe wollte ich meine HM Zwischenaktoren austauschen. Danke für das Modul es erleichtert die Sache doch ungemein :)
Ich wollte die ShellyPlugs mit ihren DNS Namen aufnehmen aber leider sagt das Modul keine gültige IP([Shelly] Invalid IP address SZ-PW-WB-LI.hugo.local of Shelly device). Über IP ist das define kein Problem.
Ist es möglich das du das Modul dahin änderst das es auch Hostnamen beim define akzeptiert?
Ich arbeite wenn möglich immer mit Hostnamen ob es auf der Arbeit oder zuhause ist.
Danke
Gruß Micha
Den DNS Namen vom Ziel System mal anpingen und schauen was passiert. Aber bitte auch vom fhem server aus. Leider kennen wir dein Netzwerk nicht. Viel erfolg.
Zitat von: 87insane am 17 Mai 2019, 07:30:11
Den DNS Namen vom Ziel System mal anpingen und schauen was passiert. Aber bitte auch vom fhem server aus. Leider kennen wir dein Netzwerk nicht. Viel erfolg.
Ich denke eher im Modul ist es nicht vorgesehen mit Namen zu arbeiten anstatt mit IP oder beidem.
Das ist in der Tat nicht vorgesehen - man braucht nicht jedesmal den DNS zu kontaktieren. Und die Shellys sollten sowieso eine feste IP-Adresse bekommen.
Wer es unbedingt haben möchte, kann die Zeilen 149/150 im Modul
return "[Shelly] Invalid IP address ".$a[2]." of Shelly device"
if( $a[2] !~ m|\d\d?\d?\.\d\d?\d?\.\d\d?\d?\.\d\d?\d?(\:\d+)?| );
auskommentieren.
LG
pah
und dann beim nächste update auch noch dran denken....
sonst gibt es wieder fragen warum die shellys "verschwunden" sind ::)
Wenn dem so sein sollte, dass weiß ich leider nicht. Aufgrund der Meldung dachte ich das... Ein Test schadet ja nicht.
Zitat von: Prof. Dr. Peter Henning am 17 Mai 2019, 08:50:58
Das ist in der Tat nicht vorgesehen - man braucht nicht jedesmal den DNS zu kontaktieren. Und die Shellys sollten sowieso eine feste IP-Adresse bekommen.
Wer es unbedingt haben möchte, kann die Zeilen 149/150 im Modul
return "[Shelly] Invalid IP address ".$a[2]." of Shelly device"
if( $a[2] !~ m|\d\d?\d?\.\d\d?\d?\.\d\d?\d?\.\d\d?\d?(\:\d+)?| );
auskommentieren.
LG
pah
Danke
ich arbeite mit DHCP reservierungen. Somit habe ich auch direkt eine Übersicht welche IP adressen im Netz schon belegt sind.
Die Shellys sind auch in ihrem eigenen WLAN
Dann mal anders rum, warum willst du unbedingt DNS wenn du IP hast und das sogar mit Übersicht?
Ich selber mache es genau wie du und finde es super. Generell würde ich immer eine IP bevorzugen außer bei dynamischen Geräten. Einen Schritt weniger der gemacht werden muss (DNS Auflösung).
Zitat von: 87insane am 17 Mai 2019, 09:11:10
Dann mal anders rum, warum willst du unbedingt DNS wenn du IP hast und das sogar mit Übersicht?
Ich selber mache es genau wie du und finde es super. Generell würde ich immer eine IP bevorzugen außer bei dynamischen Geräten. Einen Schritt weniger der gemacht werden muss (DNS Auflösung).
Weil ich mir Namen einfach besser merken kann. Und meine Devices im Netzwerk genauso heißen wie in FHEM.
Wie hast du den DNS Namen von den Shellys geändert?
Klar, namen sind einfacher. Dafür wurde DNS (auch) erfunden. War aber nur informativ für mich..es gibt ja immer wieder neue Argumente und die sind ab und zu ja auch sehr gut. Gerade hier in FHEM lernt man ja quasi nie aus.
Ich hab für alles was bei mir im Netzwerk ist, einfach eine Liste ausgedruckt und auch digital auf dem Desktop liegen. Es sind sooo viele Geräte und da habe ich auch lieber eine richtige Übersicht.
Welchen Grund sollte man haben, sich die IP-Adresse eines FHEM-Devices merken zu wollen? Ich merke mir doch auch nicht die internen Adressen meiner HomeMatic-Geräte. Die stehen - wie beim Shelly - doch im FHEM-Device als Attribut, Internal oder Reading.
Ins DNS sollten (aus Performance- UND Sicherheitsgründen) nur die Geräte, die man wirklich regelmäßig direkt per IP bedienen will.
Insofern werde ich das im Modul auch nicht ändern.
LG
pah
Zitat von: 87insane am 17 Mai 2019, 10:44:22
Wie hast du den DNS Namen von den Shellys geändert?
In meinem DNS Server direkt alias gesetzt.
Zitat von: Prof. Dr. Peter Henning am 17 Mai 2019, 10:52:57
Welchen Grund sollte man haben, sich die IP-Adresse eines FHEM-Devices merken zu wollen? Ich merke mir doch auch nicht die internen Adressen meiner HomeMatic-Geräte. Die stehen - wie beim Shelly - doch im FHEM-Device als Attribut, Internal oder Reading.
Ins DNS sollten (aus Performance- UND Sicherheitsgründen) nur die Geräte, die man wirklich regelmäßig direkt per IP bedienen will.
Insofern werde ich das im Modul auch nicht ändern.
LG
pah
Somit ist es für mich einfacher mir die Geräte zumerken für Update etc und muss keine Listen führen. Namen kann ich mir sehr gut merken
ZitatIn meinem DNS Server direkt alias gesetzt.
Okay dann haben sie in echt weiter den Shelly Namen. Dachte du hast da eine Idee gehabt, wie man den richtig ändert. So wie ich die REST API verstehe geht das aber tatsächlich. Teste ich nachher auch nochmal.
Ich muss mir nichts merken da es ja im Router steht. Der macht auch die Liste. Hinzu habe ich im FHEM Web-IF auch alle Geräte mit IP und neben allen Geräten einen online/offline Status mit klickbarem Button. Darüber lande ich direkt in dem Web-IF des Gerätes.
(Mal ein Bild als Anregung)
OK, anbei die neueste Beta-Version.
Sollte jetzt auch ohne Klimmzüge den Shelly1PW und den Shelly2.5 steuern können. Ebenso den ShellyPlug S (niedliches Teil, gerade nach 6 Monaten Verzögerung bei mir eingetrudelt).
Das Modul enthält auch bereits die Vorbereitung auf die Firmware 1.5, die bei Betätigung der lokalen Schalter am Shelly-Device automatisch eine Meldung an FHEM absetzt.
Allerdings nach derzeitigem Stand der neuen Firmware _nicht_ für den Roller Mode in Shelly2 / 2.5.
Edit: Ich ziehe am gleichen Tag noch einmal nach, hier ist das Modul mit fast vollständiger Unterstützung der neuen Firmware 1.5 - es akzeptiert also diese Nachrichten vom Shelly unmittelbar und setzt das auch im FHEM-Device. Ich grübele noch, wie ich im "Detached Switch Mode" dafür sorge, dass dann beim Tastendruck am Shelly ein FHEM-Event ausgelöst wird, ohne dass ein neues Reading geschaffen wird. Dieses FHEM-Event kann dann beliebig weiter verarbeitet werden, ändert aber den Status des FHEM-Devices erst einmal gar nicht.
LG
pah
ZitatSollte jetzt auch ohne Klimmzüge den Shelly1PW und den Shelly2.5 steuern können. Ebenso den ShellyPlug S (niedliches Teil, gerade nach 6 Monaten Verzögerung bei mir eingetrudelt).
Sollte das nicht Shelly1PM heißen?
Gruß
billy-boy
Kann sein - ich besitze das Teil nicht ;)
LG
pah
OK, ich habe die Version 2.0 des Shelly-Moduls eingecheckt.
Mit Unterstützung für
- Firmware 1.5 (mit Rückmeldung lokal ausgelöster Schaltvorgänge an FHEM, und zwar ohne MQTT)
- shelly1pm,shelly2.5 als Devicevarianten
- set <devicename> hsv <hue>,<saturation>,<value> beim shelly2rgbw
LG
pah
Edit: erfahre gerade, dass die Firmware 1.5 morgen früh released werden soll.
Top, danke Dir schonmal [emoji6]
Gesendet von meinem ONEPLUS A6003 mit Tapatalk
Hallo zusammen,
gibt es die Möglichkeit, für den Shelly1 einen "toggle" Befehl zu generieren?
Habe dazu leider nichts gefunden...
Danke und Grüße,
Ian
Zitat von: Prof. Dr. Peter Henning am 21 Mai 2019, 16:07:45
OK, ich habe die Version 2.0 des Shelly-Moduls eingecheckt.
In FHEM und im Shelly hat das Update geklappt. Nun wollte ich im Shelly 1 die neue Funktion nutzen:
In Shelly switch devices one may set URL values that are "hit" when the input or output status changes. Here one must set
For Button switched ON url: http://<FHEM IP address>:<Port>/fhem?cmd=set%20$lt;Devicename>%20button_on%20[<channel>]
For Button switched OFF url: http://<FHEM IP address>:<Port>/fhem?cmd=set%20$lt;Devicename>%20button_off%20[<channel>]
For Output switched ON url: http://<FHEM IP address>:<Port>/fhem?cmd=set%20$lt;Devicename>%20out_on%20[<channel>]
For Output switched OFF url: http://<FHEM IP address>:<Port>/fhem?cmd=set%20$lt;Devicename>%20out_off%20[<channel>]
Soweit ganz einfach, IP, Port und Devicename sind klar, aber wo bekomme ich den <channel> her?
Kann mir jemand auf die Sprünge helfen?
Gruss
Enno
Edit: Ok, wer lesen kann. channel entfällt bei Shelly 1. Dann noch den Sonderzeichenkram gerade gezogen und schon geht es. Besten Dank für das Modul:
http://192.168.1.200:8083/fhem?cmd=set%20myShelly%20button_on
Zitat von: enno am 22 Mai 2019, 20:00:58
Soweit ganz einfach, IP, Port und Devicename sind klar, aber wo bekomme ich den <channel> her?
Kann mir jemand auf die Sprünge helfen?
Die Kanäle werden bei Shelly ab 0 (Null) hochgezählt.
Zitat von: enno am 22 Mai 2019, 20:00:58
Edit: Ok, wer lesen kann. channel entfällt bei Shelly 1. Dann noch den Sonderzeichenkram gerade gezogen und schon geht es. Besten Dank für das Modul:
der "Sonderzeichenkram" ist nen Typo im commandref teil des Modul. da steht ein $, müsste aber ein & sein.
muss pah korrigieren (oder sollen wir einen patch erstellen?)
Hallo
habe gestern meinen ersten RGBW shelly bekommen.
Verzweifelt versuche ich das teil zum laufen zu bringen. 2 Shelly 1 laufen bereits in FHEM perfekt, der neue RGBW ist im eigenen webinterfache direkt auch ansteuerbar.
Meine Definition sieht wie folgt aus:
define SHL_RGB_Stripes Shelly 192.168.178.75
attr SHL_RGB_Stripes event-on-change-reading .*
attr SHL_RGB_Stripes icon hue_filled_lightstrip
attr SHL_RGB_Stripes model shellyrgbw
attr SHL_RGB_Stripes room Shelly
attr SHL_RGB_Stripes webCmd rgb:rgb ff0000:rgb 00ff00:rgb 0000ff:on:off
attr SHL_RGB_Stripes widgetOverride rgb:colorpicker,RGB
Im eventmonitor sehe ich, dass FEHM die richtigen befehle herausschickt. Leider tut sich am modul nichts.
1. Ist die Definition so richtig oder fehlt etwas ?
2. Muss ggf der shelly noch geflasht werden oder funktioniert normalerweise die Original FW bei beim Shelly 1?
3. Stehe ich komplett auf dem Schlauch ?
Danke und Grüße,
Mark
Moin zusammen!
Habe auch gestern etwas gefrickelt, bis ich es am Laufen hatte. Problem ist natürlich, dass man auch Username, Passwort und csrf-Token mit übergeben muss, wenn diese im System gesetzt sind. Der Aufruf muss dann beispielsweise für button_on wie folgt aussehen:
http://<Username>:<Password>@<IP>:<Port>/fhem?cmd=set%20<Shellyname>%20button_on&fwcsrf=<csrf_Token>&XHR=1
Komischerweise bekomme ich aber beim Abspeichern der Adressen im Shelly eine Fehlermeldung "Error! Url not saved". Trotzdem werden die Adressen richtig abgespeichert und die Rückmeldung funktioniert. Ich werde das Dimitar mal schreiben - denke das ist ein Bug bzw Schönheitsfehler in der Firmware.
@pah: Ist es eigentlich ratsam, dass man nun den Intervall auf 0 setzt, oder sollte man das Polling (ggf. mit größerer Zeit, z.B. 180) doch noch zur Sicherheit (falls mal eine Meldung verloren geht) drin lassen? Merkt man bei Intervall = 0 ggf. nicht, wenn der Shelly aus irgendeinem Grund offline sein sollte?
Nun habe ich noch eine andere Überlegung zum Thema "Alten Bewegungsmelder smart machen" (habe es noch nicht ausprobiert - sind nur Vorüberlegungen, ob das überhaupt schon so geht, wie ich es gerne hätte):
Ich würde den Bewegungsmelder so einstellen wollen, dass ich auch am Tag die Bewegung zurück gemeldet bekomme, um z.B. das aktuelle Bild der Kamera per Telegram zu schicken. Logischerweise möchte ich natürlich nicht, dass tagsüber dann auch das Licht am Hauseingang eingeschaltet wird. Nun ist meine Überlegung den Button Type auf "Detached Switch" zu setzen. Ist es in deinem Modul möglich, dass man dann auf den Eingang (an dem hängt dann der Bewegungsmelder) reagiert und per Fhem den Ausgang (hier wird die Beleuchtung angeschlossen) des gleichen Shelly schaltet?
Ich kann es nur nochmal sagen: Vielen Dank für dieses tolle Modul. Es vereinfacht die Sache ungemein!
@studiosus12: Hat dein Shelly ein Username und Passwort? Hast du die im Device in Fhem gesetzt? Was sagt der Status vom Device?
Zitat von: Cluni am 23 Mai 2019, 09:36:07
Problem ist natürlich, dass man auch Username, Passwort und csrf-Token mit übergeben muss, wenn diese im System gesetzt sind. Der Aufruf muss dann beispielsweise für button_on wie folgt aussehen:
http://<Username>:<Password>@<IP>:<Port>/fhem?cmd=set%20<Shellyname>%20button_on&fwcsrf=<csrf_Token>&XHR=1
das könnte man ja mit einem eigenen allowed (für die shellys) umgehen, oder?
Hmmmm - da könntest du Recht haben. Das habe ich mir aber ehrlich gesagt noch nicht angesehen. Ich mache das grundsätzlich so kompliziert.... :P
einfach kann ja jeder ;) ;D ;D ;D
Hallo
Ich habe zwei Dinge.
Zum Einen habe ich das Problem das Fhem das hinterlegte Passwort bei jedem "shutdown restart" vergisst.
Die shellys haben dann immer state:error. Durch ein erneutes setzen des Passworts wird state wieder korrekt ermittelt. Bis zum nächsten "shutdown" :-(
Zum Anderen habe ich eine Bitte / einen Wunsch!
Aktuell wird bei einem shelly1pm die aktuell anliegende Last in Watt in dem Reading "power" angezeigt. Das ist auch super. Es wäre aber wunderbar wenn auch der Verbrauch in einem Reading angezeigt werden würde. Der Shelly1pm hat einen Counter dafür welcher "nur" ausgelesen werden müsste.
Hier die http://IPdesShellys/settings als Rohdaten:
{"device":{"type":"SHSW-PM","mac":"DC4F2260903D","hostname":"shelly1pm-60903D","num_outputs":1,"num_meters":1},"wifi_ap":{"enabled":false,"ssid":"shelly1pm-60903D","key":""},"wifi_sta":{"enabled":true,"ssid":"xxxxx","ipv4_method":"static","ip":"xxxxx","gw":"xxxxxx","mask":"xxxxxxx","dns":"xxxxxx"},"wifi_sta1":{"enabled":false,"ssid":null,"ipv4_method":"dhcp","ip":null,"gw":null,"mask":null,"dns":null},"mqtt": {"enable":false,"server":"192.168.33.3:1883","user":"","reconnect_timeout_max":60.000000,"reconnect_timeout_min":2.000000,"clean_session":true,"keep_alive":60,"will_topic":"shellies/shelly1pm-60903D/online","will_message":"false","max_qos":0,"retain":false,"update_period":30},"sntp": {"server":"xxxxx"},"login":{"enabled":true,"unprotected":false,"username":"xxxx","password":"xxxx"},"pin_code":"","coiot_execute_enable":false,"name":"","fw":"20190522-070715/v1.5.0@a5e1e3f8","build_info":{"build_id":"20190522-070715/v1.5.0@a5e1e3f8","build_timestamp":"2019-05-22T07:07:15Z","build_version":"1.0"},"cloud":{"enabled":false,"connected":false},"timezone":"Europe/Berlin","lat":50.110901,"lng":8.682130,"tzautodetect":false,"time":"10:47","hwinfo":{"hw_revision":"prod-190329", "batch_id":1},"max_power":3500,"mode" :"relay","relays":[{"name":null,"ison":true,"has_timer":false,"default_state":"off","btn_type":"toggle","btn_reverse":0,"auto_on":0.00,"auto_off":0.00,"btn_on_url":null,"btn_off_url":null,"out_on_url":null,"out_off_url":null,"schedule":false,"schedule_rules":[],"max_power":3500}],"meters":[{"power":6.06,"is_valid":true,"timestamp":1558608426,"counters":[6.102, 6.084, 6.098],"total":1824}]}
Ganz zum Ende steht: total:1824. In dem total-Counter wird jede Minute die aktuell anliegende Last in Watt aufaddiert. Wenn man diesen Wert durch 60 teilt erhällt man die gesamt verbrauchten Wattstunden.
Danke und Gruß
Daniel
Zitatgibt es die Möglichkeit, für den Shelly1 einen "toggle" Befehl zu generieren?
Ich weiß zwar nicht, was "generieren" bedeuten soll, aber einen toggle-Befehl kann ich einbauen.
Zitatmuss pah korrigieren (oder sollen wir einen patch erstellen?)
Kriegt er gerade noch so hin...
Zitat
Komischerweise bekomme ich aber beim Abspeichern der Adressen im Shelly eine Fehlermeldung "Error! Url not saved". Trotzdem werden die Adressen richtig abgespeichert und die Rückmeldung funktioniert. Ich werde das Dimitar mal schreiben - denke das ist ein Bug bzw Schönheitsfehler in der Firmware.
Kann sein, dass das noch ein Bug in der Firmware ist - in der 1.5rc3 hatten sie ihn noch so drin, dass nicht einmal das "&" abgespeichert wurde.
Zitat@pah: Ist es eigentlich ratsam, dass man nun den Intervall auf 0 setzt, oder sollte man das Polling (ggf. mit größerer Zeit, z.B. 180) doch noch zur Sicherheit (falls mal eine Meldung verloren geht) drin lassen? Merkt man bei Intervall = 0 ggf. nicht, wenn der Shelly aus irgendeinem Grund offline sein sollte?
ich lasse das generell drin - eben wegen dem "offline". Und beim Rollladenaktor braucht man das sowieso.
ZitatIst es in deinem Modul möglich, dass man dann auf den Eingang (an dem hängt dann der Bewegungsmelder) reagiert und per Fhem den Ausgang (hier wird die Beleuchtung angeschlossen) des gleichen Shelly schaltet?
Klar. Schau Dir mal im Event-Monitor an, wann beim Tastendruck die Readings button[_x] und relay[_x] gesetzt werden. Das geht im detached mode komplett unabhängig voneinander. Und da Tastendruck und Tastenloslassen separate Events sind (allerdings nicht beim ShellyPlug S), kann man mit einem Schalter (Taster) sogar wie bei Homematic verschiedene Vorgänge auslösen.
Zitat1. Ist die Definition so richtig oder fehlt etwas ?
Ja, Nein.
Zitat2. Muss ggf der shelly noch geflasht werden oder funktioniert normalerweise die Original FW bei beim Shelly 1?
Nein, Ja
Zitat3. Stehe ich komplett auf dem Schlauch ?
Woher soll ich denn das wissen?
ZitatEs wäre aber wunderbar wenn auch der Verbrauch in einem Reading angezeigt werden würde.
Mach ich.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 23 Mai 2019, 15:40:59
Klar. Schau Dir mal im Event-Monitor an, wann beim Tastendruck die Readings button[_x] und relay[_x] gesetzt werden. Das geht im detached mode komplett unabhängig voneinander. Und da Tastendruck und Tastenloslassen separate Events sind (allerdings nicht beim ShellyPlug S), kann man mit einem Schalter (Taster) sogar wie bei Homematic verschiedene Vorgänge auslösen.
Ja das ist ja wirklich geil. Ich hatte gestern auf dem Heimweg von der Arbeit darüber nachgedacht, ob ich das überhaupt mit einem einzigen Shelly 1 für Bewegungsmelder / Beleuchtung so hinbekomme. Zur Not hätte ich es halt mit einem Shelly 2 gemacht - Eingangs auf 1 und Ausgang auf 2. Aber so ist natürlich um Längen eleganter... ;)
Ich habe gerade Version 2.01 eingecheckt, mit den genannten Ergänzungen. Achtung: energy als Reading (in Ws) gibt es nicht bei allen Devices, z.B. nicht beim RGBW2
Im Prinzip müsste ich jetzt noch den Befehl "get ... registers" anpassen. Das muss aber warten, habe außer FHEM und Golfspielen noch anderes zu erledigen...
LG
pah
So, ich habe eben mit Dimitar per Whatsapp geredet. Er kannte diesen Fehler noch nicht, aber seine Techniker konnten das Problem nach wenigen Versuchen nachvollziehen. Der Fehler betrifft anscheinend nur den Shelly 1 und soll bis Ende nächster Woche behoben werden.
Man kann nur es immer wieder betonen: Die Jungs und deren Support sind phänomenal!
Ich weiß - dieser Post gehört eigentlich in den Hardware-Thread, aber da es hier im Verlauf aufgetreten ist habe ich mich für die Antwort hier entschieden...
Hallo
@Cluni
kein Passwort - kein username vergeben
Status ist: network connected & state initialized
In der Hilfe hab ich noch gefunden den mode zu definieren attr SHL_RGB_Stripes mode color (für RGB´s) - dieses mode wird aber überhaupt nicht angenommen bzw nicht definiert,....
Viele GRüße
Zitat von: Prof. Dr. Peter Henning am 23 Mai 2019, 15:40:59
Ich weiß zwar nicht, was "generieren" bedeuten soll, aber einen toggle-Befehl kann ich einbauen.
Hallo pah,
mit "generieren" meinte ich, ob es evtl. eine Befehlsfolge gibt, die zu einem "toggeln" führt.
Wenn Du den Befehl direkt einbinden könntest, wäre das natürlich super!
Danke,
Ian
Zitat
In der Hilfe hab ich noch gefunden den mode zu definieren attr SHL_RGB_Stripes mode color (für RGB´s) - dieses mode wird aber überhaupt nicht angenommen bzw nicht definiert,....
Kann ihm vielleicht jemand beibringen, a.) ordentliche Fehlermeldungen abzugeben und b.) sein model-Attribut richtig zu setzen ? Mich hat der Post so deprimiert, dass ich die Kraft dafür nicht aufbringe...
pah
Zitat von: Prof. Dr. Peter Henning am 23 Mai 2019, 15:40:59
aber einen toggle-Befehl kann ich einbauen.
oder die setExtensions einbinden, dann hättest du auf einen Schlag noch etliche Kommandos mehr :)
Für die Shellys mit nur einem Kanal (bzw. beim 2/2.5 mit defchannel) sollte das mit wenig Aufwand direkt aus dem Stand klappen.
Für den zweiten Kanal ist es leider nicht ganz so einfach, da die Kanalnummer noch mit in den simplen set on/off Befehl muß,
Das Problem hatte ich damals bei meinem 96_UbiquitiMP Modul auch.
Zitat von: Wzut am 24 Mai 2019, 07:21:44
Für den zweiten Kanal ist es leider nicht ganz so einfach, da die Kanalnummer noch mit in den simplen set on/off Befehl muß,
(bißchen OT: ist dir das mit den SetExtensions für weitere Kanäle gelungen? Ich hatte neulich im Zusammenhang mit MySensors eine Diskussion mit Rudi und da hatte ich den Eindruck, das ginge gar nicht vernünftig. Ich hab's dann für weitere Kanäle nicht weiterverfolgt, weil man "notfalls" ja auch einen ReadingsProxy zwischenschalten kann, um die "SetExtensions-fähig" zu machen.)
Zurück zu topic:
Die Einbindung der SetExtensions für einkanalige ist wirklich easy.
Und da alle laufenden Timer (auch off-till, blink usw.) zwischenzeitlich in den Internals sichtbar sind, kann man auch den Zustand (allermeistens) ordentlich visualisieren, wenn man das möchte.
Erstens habe ich "toggle" in die aktuelle Version bereits eingebaut (für alle Kanäle), timer-Kommandos gab es schon immer.
Zweitens ist dieses relativ schlanke und klare Modul deshalb schlank und klar, weil es so weit wie nötig und möglich die Fähigkeiten der Shellys selber nutzt (etwa deren internen Timer). In diesen Fällen sind also die SetExtensions eher ein Klotz am Bein.
Drittens haben die Shellys ziemlich unterschiedliche Fähigkeiten, die API-Aufrufe sind insbesondere beim 2/2.5 und RGBW2 je nach internem mode etwas komplexer, als dass dies mit SetExtensions einfach lösbar wäre.
LG
pah
Hallo pah,
DANKE für Deinen sehr schnellen support... 8)
"toggle" funktioniert bei mir mit der letzten 36_Shelly.pm-Version von gestern mittag leider nicht - "on"/"off" funktioniert problemlos, bei "toggle" erfolgt keine Reaktion.
Oder mache ich etwas falsch?
Danke für eine Hinweis,
Ian
Zitatmit der letzten 36_Shelly.pm-Version
::)
Geht es genauer? Warum um Himmels Willen schreibe ich ein Modul mit einem "get version"-Befehl?
pah
Zitat von: Prof. Dr. Peter Henning am 23 Mai 2019, 16:25:16
Ich habe gerade Version 2.01 eingecheckt, mit den genannten Ergänzungen. Achtung: energy als Reading (in Ws) gibt es nicht bei allen Devices, z.B. nicht beim RGBW2
Im Prinzip müsste ich jetzt noch den Befehl "get ... registers" anpassen. Das muss aber warten, habe außer FHEM und Golfspielen noch anderes zu erledigen...
LG
pah
Zum Thema Version,
ich habe gestern um 20:30 ein update im FHEM durchgeführt, aber das Modul 36_shelly hat kein update erfahren.
Gibt es da noch eine Verzögerung zwischen dem einchecken und der Bereitstellung zum Update ?
Ich habe immer noch Version 2.0 leider nicht 2.01, kann das aber erst heute abend erneut prüfen.
Gibt es irgendwelche Voraussetzungen damit meine Installation das Update erkennen kann ?
Gruss
Bombardi
Zitat von: enno am 22 Mai 2019, 20:00:58
In FHEM und im Shelly hat das Update geklappt. Nun wollte ich im Shelly 1 die neue Funktion nutzen:
In Shelly switch devices one may set URL values that are "hit" when the input or output status changes. Here one must set
For Button switched ON url: http://<FHEM IP address>:<Port>/fhem?cmd=set%20$lt;Devicename>%20button_on%20[<channel>]
For Button switched OFF url: http://<FHEM IP address>:<Port>/fhem?cmd=set%20$lt;Devicename>%20button_off%20[<channel>]
For Output switched ON url: http://<FHEM IP address>:<Port>/fhem?cmd=set%20$lt;Devicename>%20out_on%20[<channel>]
For Output switched OFF url: http://<FHEM IP address>:<Port>/fhem?cmd=set%20$lt;Devicename>%20out_off%20[<channel>]
Soweit ganz einfach, IP, Port und Devicename sind klar, aber wo bekomme ich den <channel> her?
Kann mir jemand auf die Sprünge helfen?
Gruss
Enno
Edit: Ok, wer lesen kann. channel entfällt bei Shelly 1. Dann noch den Sonderzeichenkram gerade gezogen und schon geht es. Besten Dank für das Modul:
http://192.168.1.200:8083/fhem?cmd=set%20myShelly%20button_on
Dazu noch eine Frage:
Dieser Aufruf mit meiner IP-Adresse und dem Devicenamen aus meinem FHEM funktioniert bei mir nicht.
Die Beschreibung vom Shelly Modul hat sich seit gestern geändert
url: http://<FHEM IP address>:<Port>/fhem?XHR=1&cmd=set%20<Devicename>%20button_on%20[<channel>]
Reicht das XHR=1 wenn man den csrfToken aktiv hat oder muss ich den noch zusätzlich irgendwo angeben.
Bitte mal ein funktionsfähiges Beispiel mit csrfToken posten
Gruss
Bombardi
Zitat von: Prof. Dr. Peter Henning am 24 Mai 2019, 05:17:30
Kann ihm vielleicht jemand beibringen, a.) ordentliche Fehlermeldungen abzugeben und b.) sein model-Attribut richtig zu setzen ? Mich hat der Post so deprimiert, dass ich die Kraft dafür nicht aufbringe...
pah
Hallo
leider in ich kein Vollblut Programmierer sondern lediglich Anwender. Bitte um etwas Nachsicht.
Grüße
Zitat von: bombardi am 24 Mai 2019, 10:39:43
url: http://<FHEM IP address>:<Port>/fhem?XHR=1&cmd=set%20<Devicename>%20button_on%20[<channel>]
Reicht das XHR=1 wenn man den csrfToken aktiv hat oder muss ich den noch zusätzlich irgendwo angeben.
Bitte mal ein funktionsfähiges Beispiel mit csrfToken posten
Ihr solltet euch wohl mal die Mühe machen und ein paar Beiträge früher lesen... ::)
https://forum.fhem.de/index.php/topic,93251.msg942525.html#msg942525
Zitat von: bombardi am 24 Mai 2019, 10:31:35
Zum Thema Version,
ich habe gestern um 20:30 ein update im FHEM durchgeführt, aber das Modul 36_shelly hat kein update erfahren.
die Änderung von pah wurde gestern nachmittag/abend eingecheckt....
wer möchte kann auch gerne dort --> https://forum.fhem.de/index.php/board,57.0.html mal nachgucken
Zitat von: bombardi am 24 Mai 2019, 10:31:35
Gibt es da noch eine Verzögerung zwischen dem einchecken und der Bereitstellung zum Update ?
Ich habe immer noch Version 2.0 leider nicht 2.01, kann das aber erst heute abend erneut prüfen.
Gibt es irgendwelche Voraussetzungen damit meine Installation das Update erkennen kann ?
wenn du das fhem update benutzt, wird erst jeden morgen um 8.00 Uhr die neue Version zur Verfügung gestellt. --> https://wiki.fhem.de/wiki/Update oder https://commandref.fhem.de/#update
d.h. heute abend wenn du updatest, bekommst du die aktuelle Version (2.01)
zum csrf-token:
https://wiki.fhem.de/wiki/CsrfToken-HowTo#API_Web
oder
https://wiki.fhem.de/wiki/CsrfToken-HowTo#csrfToken_festlegen
Zitat von: bombardi am 24 Mai 2019, 10:31:35
Zum Thema Version,
ich habe gestern um 20:30 ein update im FHEM durchgeführt, aber das Modul 36_shelly hat kein update erfahren.
Gibt es da noch eine Verzögerung zwischen dem einchecken und der Bereitstellung zum Update ?
https://fhem.de/commandref_DE.html#update
Zitat
Zu beachten:
Das contrib Verzeichnis wird nicht heruntergeladen.
Die Dateien werden auf der Webseite einmal am Tag um 07:45 MET/MEST aus der Quell-Verwaltungssystem (SVN) bereitgestellt.
Das all Argument ist die Voreinstellung.
Das force Argument beachtet die lokale controls_fhem.txt Datei nicht.
Das check Argument zeigt die neueren Dateien an, und den letzten Abschnitt aus der CHANGED Datei
checktime zeigt zusätzlich zu check den update-Zeitstempel der neuen Datei, üblicherweise version Zeitstempel +1 Tag.
Falls man <fileName> spezifiziert, dann werden nur die Dateien heruntergeladen, die diesem Regexp entsprechen.
Die Faustregel besagt, dass eingecheckte Änderungen ab ca. 08:00 Uhr des Folgetages per Update bezogen werden können
Gruß Benni.
Zitat von: studiosus12 am 24 Mai 2019, 10:40:16
Hallo
leider in ich kein Vollblut Programmierer sondern lediglich Anwender. Bitte um etwas Nachsicht.
Grüße
https://tty1.net/smart-questions_de.html
Zitat von: Cluni am 24 Mai 2019, 10:44:09
Ihr solltet euch wohl mal die Mühe machen und ein paar Beiträge früher lesen... ::)
https://forum.fhem.de/index.php/topic,93251.msg942525.html#msg942525
Ich habe für solche Aufgaben eine separate FHEMWEB-Instanz (separater Port), die ich auch ausschließlich dafür verwende.
Die hat keine csrf-Token gesetzt und ist auch sonst nicht geschützt.
Gruß Benni.
Bombardi aber anscheinend nicht....
Gesendet von iPhone XR mit Tapatalk
Zitatleider in ich kein Vollblut Programmierer
ich in auch kein Vollblut Programmierer, was immer das sein mag.
Die Art der Fragestellung hat damit aber auch nichts zu tun - zwei meiner drei Kinder sind Geisteswissenschaftler und haben trotzdem gelernt, sinnvolle Fragen zu stellen. Benni ist mir leider mit seinem Zitat zuvorgekommen...
Also bitte erst lesen, dann noch einmal lesen - und dann eine Frage stellen.
LG
pah
Ich habe auch eine zusätzliche Instanz, aber die habe ich trotzdem abgeriegelt mit eigener Sicherheit. Von daher finde ich die Frage von bombardi schon legitim - wenn ich diese Frage nicht schon eine Seite vorher beantwortet hätte...
Danke für die vielen Hinweise zu meinen Fragen,
jetzt ist mir auch klar warum das Beispiel von enno normalerweise nicht funktionieren kann, weill der csrfToken Standard ist.
Cluni deinen Eintrag hatte ich gelesen, nach dem von Enno aber fälschlicherweise gedacht, das dies eher die Ausnahme als die Regel ist.
Jetzt werde ich meine Instanz mit einem festen Token versehen und dann sehen wir weiter.
Ein Standard user und Passwort ist aber nicht vergeben oder habe ich da noch etwas übersehen/vergessen.
Gruss
Bombardi
sieht benni meine antworten nicht? :o ;D ;D ;D
hallo benni :-*
Zitat von: Prof. Dr. Peter Henning am 24 Mai 2019, 12:28:13
ich in auch kein Vollblut Programmierer, was immer das sein mag.
vielleicht das hier: https://de.wikipedia.org/wiki/Vollbl%C3%BCter ??
wobei... mit hufen tippt es sich schlecht ::) ::)
Zitat von: Prof. Dr. Peter Henning am 24 Mai 2019, 12:28:13
zwei meiner drei Kinder sind Geisteswissenschaftler und haben trotzdem gelernt, sinnvolle Fragen zu stellen.
ymmd.... ;D ;D ;D
wie konnte das nur passieren? :o
Zitat von: Prof. Dr. Peter Henning am 24 Mai 2019, 09:55:33
::)
Geht es genauer? Warum um Himmels Willen schreibe ich ein Modul mit einem "get version"-Befehl?
pah
Unabhängig davon, dass ihr euch viel Mühe gebt und anscheinend echt Plan habt, finde ich eure teils aggressiven Reaktionen komplett überflüssig... :-\
Ich habe Deinen "get version" Befehl gesehen, habe aber versehentlich als Name "Shelly" eingegeben - mir war nicht klar, dass der Name der meines Aktuators sein soll.
Meine Version ist 2.0, obwohl ich heute gegen 09:10 aktualisiert habe - folglich kann irgendwas mit der update Zeit nicht passen...
Egal - ich werde nachher erneut ein update durchführen.
Danke.
EDIT:
Habe gerade eben (16:50) ein neues update gezogen. In Version 2.01 funktioniert es einwandfrei!
DANKE nochmal, pah
und danach einen shutdown restart oder zumindest reload 36_Shelly ?
Ich habe eben die 2.01 via update bekommen.
Zitat von: nils_ am 24 Mai 2019, 12:49:47
sieht benni meine antworten nicht? :o ;D ;D ;D
hallo benni :-*
Doch, nur leider zu spät! :-\
Aber vielleicht hält doppelt ja besser ;)
Gruß Benni.
@noom0815: Wir sind ein freies Land. Niemand wird gezwungen, die grundlegenden Dokumentationen zu lesen - aber dann sollte er sich doch bitte überlegen, sich andere Software zu suchen.
pah
Moin!
ich habe eine Shelly2 und wollte auch die URLs eintragen. Meine Reading für die Channel heißen jedoch relay_0 und relay_1. Ich habe schon versucht in der URL button durch relay zu ersetzen aber das klappt nicht. Durch Versuche mit button in der URL wurde die Readings button_0 und button_1 angelegt.
Sind die URLs nur als Benachrichtigung zu verstehen und man muss selber darauf reagieren oder sollen die auch was auslösen?
Vielen Dank und ein schönes Wochenende
Mathias
Zitat von: m_gatz am 25 Mai 2019, 10:16:16
Meine Reading für die Channel heißen jedoch relay_0 und relay_1. Ich habe schon versucht in der URL button durch relay zu ersetzen aber das klappt nicht.
https://fhem.de/commandref.html#Shelly
Zitat
In Shelly switch devices one may set URL values that are "hit" when the input or output status changes. Here one must set
For Button switched ON url: http://<FHEM IP address>:<Port>/fhem?XHR=1&cmd=set%20<Devicename>%20button_on%20[<channel>]
For Button switched OFF url: http://<FHEM IP address>:<Port>/fhem?XHR=1&cmd=set%20<Devicename>%20button_off%20[<channel>]
For Output switched ON url: http://<FHEM IP address>:<Port>/fhem?XHR=1&cmd=set%20<Devicename>%20out_on%20[<channel>]
For Output switched OFF url: http://<FHEM IP address>:<Port>/fhem?XHR=1&cmd=set%20<Devicename>%20out_off%20[<channel>]
Attention: Of course, a csrfToken must be included as well - or a proper allowed device declared.
Output ist der Ausgang = das Relay, bzw. der Schaltzustand des Relays
Nicht vergessen, bei Shelly 2 den Channel (0 oder 1) in der URL anzugeben
Zitat von: m_gatz am 25 Mai 2019, 10:16:16
Sind die URLs nur als Benachrichtigung zu verstehen und man muss selber darauf reagieren oder sollen die auch was auslösen?
Ja, nein, ja!
Der Shelly schickt über die URL den entsprechenden trigger (Event) an das Shelly-Device in FHEM. Die Ereignisbehandlung des Events wird vom Shelly-Device in FHEM ab Modulversion 2.0.0 implizit übernommen.
Du kannst über die URL auch ein beliebiges anderes Device in FHEM schalten, oder einen anderen Shelly direkt, oder IFTTT, oder was auch immer per Webhook erreichbar ist ;)
gb#
Einfach mal die CommandRef lesen.
::)
LG
pah
Hallo pah,
mir ist nun auch aufgefallen, dass meine Shellys nach einem Neustart immer auf "Error!" stehen. Ursprünglich dachte ich ja auch, dass das ein Problem mit dem Passwort wäre, aber dem scheint nicht so zu sein. Sobald ich ein get status oder einen Schaltbefehl ausführe, verschwindet der Fehler. Kannst du dir darauf einen Reim machen? Wird der Status beim Fhem-Neustart ggf. zu einem ungünstigen Zeitpunkt geprüft oder hast du einen Rat, wie man diese Problem umgehen kann? Hatte schon überlegt einen Timer bei Systemstart auf bsw. 2 Minuten zu setzen und automatisch ein get status zu machen, aber das ist ja dann gefrickelt und sehr unschön...
LG Bernd
Zitat von: Cluni am 27 Mai 2019, 12:22:30
Hallo pah,
mir ist nun auch aufgefallen, dass meine Shellys nach einem Neustart immer auf "Error!" stehen. Ursprünglich dachte ich ja auch, dass das ein Problem mit dem Passwort wäre, aber dem scheint nicht so zu sein. Sobald ich ein get status oder einen Schaltbefehl ausführe, verschwindet der Fehler. Kannst du dir darauf einen Reim machen? Wird der Status beim Fhem-Neustart ggf. zu einem ungünstigen Zeitpunkt geprüft oder hast du einen Rat, wie man diese Problem umgehen kann? Hatte schon überlegt einen Timer bei Systemstart auf bsw. 2 Minuten zu setzen und automatisch ein get status zu machen, aber das ist ja dann gefrickelt und sehr unschön...
LG Bernd
Hallo Bernd,
Stell mal bitte ein Shelly Device welches diesen Fehler hat auf verbose 5 und starte dann neu. Vorher speichern nicht vergessen ;D
2019.05.27 12:32:56 1: [Shelly_status] invalid JSON data
2019.05.27 12:32:56 5: [Shelly_status] has obtained data 401 Unauthorized
2019.05.27 12:32:56 1: [Shelly_status] invalid JSON data
2019.05.27 12:32:56 1: [Shelly_status] invalid JSON data
Nach get status steht folgendes im Log:
2019.05.27 12:38:45 5: [Shelly_status] Issue a non-blocking call to http://Cluni:meinPW@192.168.0.150:80/status
2019.05.27 12:38:45 5: [Shelly_status] has obtained data {"wifi_sta":{"connected":true,"ssid":"Virus4free","ip":"192.168.0.150","rssi":-37},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":false},"time":"12:38","serial":1,"has_update":false,"mac":"CC50E350024D","relays" :[{"ison":false, "has_timer":false}],"meters":[{"power":0.00,"is_valid":"true"}],"update":{"status":"idle","has_update":false,"new_version":"20190522-070313/v1.5.0@a5e1e3f8","old_version":"20190522-070313/v1.5.0@a5e1e3f8"},"ram_total":51104,"ram_free":40820,"fs_size":233681,"fs_free":170429,"uptime":358429}
Zu aller erst mal vorweg: Ich bin inzwischen ein echter Shelly-Fan! ;D
Toll was die kleinen Dinger können! Super Preis-Leistungsverhältnist und mit Pahs Modul super simpel, quasi out-of-the-box einzurichten. Danke dafür!
So, jetzt zu meinem eigentlichen Anliegen:
Was mich bei meinem Shelly 2 bei der Shelly-Modulumsetzung im Relay-Mode "gestört" hat ist, dass ich die beiden Ausgänge (Relays) nicht als Kanäle (und somit als eigenständige Devices) des Hauptdevices zur Verfügung habe. Also so wie es bspw. bei Homematic HM-Lc-SW2-Fm der Fall ist. Da ich bisher vor allem HM im Einsatz habe, bin ich das so gewöhnt und wollte das an der Stelle auch so haben.
Ich habe mir das dann einfach mit 2 readingsProxy (https://fhem.de/commandref_DE.html#readingsProxy) selbst gebastelt. Vielleicht teilt ja jemand meine "Leidenschaft" für Kanal-Devices?
Hier mal ein rudimentäres List des Haupt-Devices, also des eigentlichen Shelly-Devices:
Internals:
DEF 192.168.*.*
FUUID 5ce02482-f33f-b8e7-22a9-5af5379d64542569
FVERSION 36_Shelly.pm:v2.0.0-s19432/2019-05-21
INTERVAL 60
NAME EG.BD.SW.Main
NR 959
STATE 0 W
TCPIP 192.168.*.*:80
TYPE Shelly
READINGS:
2019-05-18 17:28:02 cloud disabled
2019-05-18 21:30:28 config mode=relay=
2019-05-27 15:31:23 energy 7.1
2019-05-22 19:25:05 firmware v1.5.0
2019-05-26 07:08:39 network connected
2019-05-27 15:30:22 overpower_0 false
2019-05-27 15:30:21 overpower_1 false
2019-05-27 15:30:23 power 0
2019-05-27 15:30:22 relay_0 off
2019-05-27 15:30:21 relay_1 off
2019-05-27 15:30:22 state OK
Attributes:
DbLogExclude .*
defchannel 0
mode relay
model shelly2
room System->Shelly,EG->Bad
shellyuser fhem
stateFormat power W
webCmd :
Da ich ja nachher den Schaltzustand der Relays in den einzelnen proxy-Devices habe, habe ich mir hier über stateFormat noch die aktuell gemessene Leistung als Anzeigewert eingetragen.
Hier die beiden readingsProxy-Devices, die jeweils die beiden Realy-Readings des Haupt-Devices wiedergeben:
Internals:
DEF EG.BD.SW.Main:relay_0
DEVICE EG.BD.SW.Main
FUUID 5ce1ab27-f33f-b8e7-7fef-5aac7a21cca92bd0
NAME EG.BD.SW.Main_00.Spiegel
NOTIFYDEV global,EG.BD.SW.Main
NR 975
NTFY_ORDER 50-rpBadSpiegel
READING relay_0
STATE off
TYPE readingsProxy
CONTENT:
EG.BD.SW.Main 1
READINGS:
2019-05-27 15:30:22 lastCmd off
2019-05-27 15:30:22 state off
Attributes:
alias Bad Spiegel
group Licht
icon light_mirror
room EG->Bad
setFn {$CMD." 0"}
setList on off
Internals:
DEF EG.BD.SW.Main:relay_1
DEVICE EG.BD.SW.Main
FUUID 5ce5a411-f33f-b8e7-1822-8cadb1737a4e6d59
NAME EG.BD.SW.Main_01.Decke
NOTIFYDEV global,EG.BD.SW.Main
NR 3389
NTFY_ORDER 50-rpBadDecke
READING relay_1
STATE off
TYPE readingsProxy
CONTENT:
EG.BD.SW.Main 1
READINGS:
2019-05-27 15:30:21 lastCmd off
2019-05-27 15:30:21 state off
Attributes:
group Licht
icon light_downlight
ipAlias Bad Decke
room EG->Bad
setFn {$CMD." 1"}
setList on off
Interessant sind bei den beiden Devices v.a. die Attribute setFn und setList.
Per setFn wird festgelegt, wie ein set am jeweiligen proxy-Device eine entsprechende Umsetzung am Hauptdevice vornimmt.
Hier wird also bspw. ein set EG.BD.SW.Main_01.Decke on durchgeschleust ans Hauptdevice als set EG.BD.SW.Main on 1.
Durch das setzen des Attrbuts setList auf [on off] hat zur Folge, dass beim proxy-Device automatisch setExtensions aktiviert werden, sprich damit ist u.a. automatisch auch ein toggle verfügbar. Auch die anderen, wie etwa on-for-timer werden mit der o.g. setFn korrekt durchgeschleust.
Für die Umsetzung der [on-for-timer] und der anderen müsste setFn entsprechend erweitert werden. Da ich das aber so gut wie nie brauche, habe ich mir das erst mal gespart.
Wie gesagt: Vielleicht kann's ja jemand gebrauchen. ;)
Btw.: Ich wusste nicht so recht, ob ich das hier posten soll, oder in Codeschnipsel, habe mich dann aber (offensichtlich) für hier entischieden.
gb#
Edit: Anpassung nach Pahs Anmerkung aus folgendem Post: https://forum.fhem.de/index.php/topic,93251.msg944004.html#msg944004
N'abend allerseits!
Ich habe einen Shelly_1 und FHEM auf einem Raspberry Pi mit dem Modul 36_Shelly.pm Version 2.01 von phenning = ,pah'.
Die Internals vom Shelly_1 lauten:
DEF 192. *** . *** . ***
FUUID ****...
INTERVAL 10
NAME Ankleide_Taster
NR 743
STATE on
TCPIP 192.*** . *** . ***:80
TYPE Shelly
READINGS:
2019-02-02 19:03:43 cloud disabled
2019-05-25 09:20:03 firmware v1.5.0
2019-05-27 19:30:03 network connected
2019-05-24 19:25:39 relay on
2019-02-02 19:03:43 relay_0 off
2019-05-27 19:30:03 state on
Attributes:
group Licht_Nebenraeume
icon taster@black
interval 10
model shelly1
room Shelly
Der Shelly 1 ist immer auf on und versorgt ein OSRAM-Lightify mit Strom. Die Internals von der Lightify-Leuchte lauten:
CHANGED
DEF DFA4050000261884 IODev=Lightify
FUUID ****...
FVERSION 31_HUEDevice.pm:0.192010/2019-04-16
ID ****...
INTERVAL
IODev Lightify
NAME LIGHTIFYDFA4050000261884
NR 742
STATE dim06%
TYPE HUEDevice
desired 1
type Dimmable
uniqueid DFA4050000261884
READINGS:
2019-05-27 03:36:33 bri 10
2019-05-24 18:40:35 ct 370 (2702K)
2019-05-27 19:30:07 onoff 1
2019-05-27 19:30:07 pct 4
2019-05-27 03:36:31 reachable 1
2019-05-27 19:30:07 state dim06%
helper:
alert
bri 10
colormode
ct 370
devtype
effect
hue -1
on 1
pct 4
reachable 1
rgb
sat -1
transitiontime 0
type 4
update_timeout 1
xy
Attributes:
IODev Lightify
alias Ankleide
color-icons 2
devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
group Licht_Nebenraeume
icon light_control@orange
mqttDefaults pub:qos=0 sub:qos=2 retain=0
mqttPublish *:topic=Lichter/Ankleide
mqttSubscribe state:stopic=Lichter/Ankleide/set
room Allgemein,LIGHTIFY
subType dimmer
webCmd pct:on:off
Folgendes DOIF soll die OSRAM-Lightify anschalten beim Betreten des Ankleide-Zimmers:
([Sensor_Ankleide_Schrank] eq "open" and [Motion_Sensor_1:reportedState] eq "open" and [Motion_Sensor_1:luminance:d]<50) (set LIGHTIFYDFA4050000261884 on)
Motion_Sensor_1 ist ein ZWave https://www.fibaro.com/de/products/motion-sensor/ .
Nun zu meinem Problem:
Ich habe ständig Probleme mit der Netzwerkverbindung zum Shelly_1. Ich habe ein FileLog_Ankleide_Taster erstellt und erhalte folgende Log's:
2019-05-26_09:54:49 Ankleide_Taster Error
2019-05-26_09:54:49 Ankleide_Taster network: not connected
2019-05-26_09:54:54 Ankleide_Taster network: connected
2019-05-26_09:54:54 Ankleide_Taster on
2019-05-26_09:55:04 Ankleide_Taster Error
2019-05-26_09:55:05 Ankleide_Taster network: not connected
2019-05-26_09:55:10 Ankleide_Taster network: connected
2019-05-26_09:55:10 Ankleide_Taster on
2019-05-26_09:58:50 Ankleide_Taster Error
2019-05-26_09:58:51 Ankleide_Taster network: not connected
2019-05-26_09:59:04 Ankleide_Taster Error
2019-05-26_09:59:04 Ankleide_Taster network: not connected
2019-05-26_09:59:13 Ankleide_Taster Error
2019-05-26_09:59:13 Ankleide_Taster network: not connected
2019-05-26_09:59:22 Ankleide_Taster Error
2019-05-26_09:59:23 Ankleide_Taster network: not connected
2019-05-26_09:59:32 Ankleide_Taster Error
2019-05-26_09:59:32 Ankleide_Taster network: not connected
2019-05-26_09:59:38 Ankleide_Taster network: connected
2019-05-26_09:59:38 Ankleide_Taster on
2019-05-26_10:06:11 Ankleide_Taster Error
2019-05-26_10:06:12 Ankleide_Taster network: not connected
2019-05-26_10:06:21 Ankleide_Taster network: connected
2019-05-26_10:06:21 Ankleide_Taster on
2019-05-26_10:32:06 Ankleide_Taster Error
2019-05-26_10:32:06 Ankleide_Taster network: not connected
2019-05-26_10:32:16 Ankleide_Taster Error
2019-05-26_10:32:16 Ankleide_Taster network: not connected
2019-05-26_10:32:25 Ankleide_Taster Error
2019-05-26_10:32:25 Ankleide_Taster network: not connected
2019-05-26_10:32:33 Ankleide_Taster network: connected
2019-05-26_10:32:33 Ankleide_Taster on
2019-05-26_10:32:43 Ankleide_Taster Error
2019-05-26_10:32:43 Ankleide_Taster network: not connected
2019-05-26_10:32:52 Ankleide_Taster Error
2019-05-26_10:32:52 Ankleide_Taster network: not connected
2019-05-26_10:32:58 Ankleide_Taster network: connected
2019-05-26_10:32:58 Ankleide_Taster on
2019-05-26_11:17:58 Ankleide_Taster Error
2019-05-26_11:17:58 Ankleide_Taster network: not connected
2019-05-26_11:18:07 Ankleide_Taster Error
2019-05-26_11:18:07 Ankleide_Taster network: not connected
2019-05-26_11:18:16 Ankleide_Taster Error
2019-05-26_11:18:16 Ankleide_Taster network: not connected
2019-05-26_11:18:26 Ankleide_Taster Error
2019-05-26_11:18:26 Ankleide_Taster network: not connected
2019-05-26_11:18:35 Ankleide_Taster Error
2019-05-26_11:18:35 Ankleide_Taster network: not connected
2019-05-26_11:18:44 Ankleide_Taster Error
2019-05-26_11:18:44 Ankleide_Taster network: not connected
2019-05-26_11:18:52 Ankleide_Taster Error
2019-05-26_11:18:52 Ankleide_Taster network: not connected
2019-05-26_11:18:58 Ankleide_Taster network: connected
2019-05-26_11:18:58 Ankleide_Taster on
2019-05-26_11:36:44 Ankleide_Taster Error
2019-05-26_11:36:44 Ankleide_Taster network: not connected
2019-05-26_11:36:49 Ankleide_Taster network: connected
2019-05-26_11:36:49 Ankleide_Taster on
2019-05-26_17:38:43 Ankleide_Taster Error
2019-05-26_17:38:43 Ankleide_Taster network: not connected
2019-05-26_17:38:55 Ankleide_Taster network: connected
2019-05-26_17:38:55 Ankleide_Taster on
2019-05-26_18:29:08 Ankleide_Taster Error
2019-05-26_18:29:08 Ankleide_Taster network: not connected
2019-05-26_18:29:21 Ankleide_Taster network: connected
2019-05-26_18:29:21 Ankleide_Taster on
2019-05-26_18:29:50 Ankleide_Taster Error
2019-05-26_18:29:50 Ankleide_Taster network: not connected
2019-05-26_18:30:00 Ankleide_Taster network: connected
2019-05-26_18:30:00 Ankleide_Taster on
2019-05-26_22:28:42 Ankleide_Taster Error
2019-05-26_22:28:42 Ankleide_Taster network: not connected
2019-05-26_22:28:53 Ankleide_Taster network: connected
2019-05-26_22:28:53 Ankleide_Taster on
2019-05-27_07:56:04 Ankleide_Taster Error
2019-05-27_07:56:04 Ankleide_Taster network: not connected
2019-05-27_07:56:14 Ankleide_Taster network: connected
2019-05-27_07:56:14 Ankleide_Taster on
2019-05-27_08:27:05 Ankleide_Taster Error
2019-05-27_08:27:05 Ankleide_Taster network: not connected
2019-05-27_08:27:41 Ankleide_Taster Error
2019-05-27_08:27:41 Ankleide_Taster network: not connected
2019-05-27_08:28:02 Ankleide_Taster Error
2019-05-27_08:28:02 Ankleide_Taster network: not connected
2019-05-27_08:28:30 Ankleide_Taster Error
2019-05-27_08:28:30 Ankleide_Taster network: not connected
2019-05-27_08:28:41 Ankleide_Taster network: connected
2019-05-27_08:28:41 Ankleide_Taster on
2019-05-27_19:02:35 Ankleide_Taster Error
2019-05-27_19:02:35 Ankleide_Taster network: not connected
2019-05-27_19:02:46 Ankleide_Taster network: connected
2019-05-27_19:02:46 Ankleide_Taster on
2019-05-27_19:07:04 Ankleide_Taster Error
2019-05-27_19:07:04 Ankleide_Taster network: not connected
2019-05-27_19:07:18 Ankleide_Taster network: connected
2019-05-27_19:07:18 Ankleide_Taster on
2019-05-27_19:29:52 Ankleide_Taster Error
2019-05-27_19:29:53 Ankleide_Taster network: not connected
2019-05-27_19:30:03 Ankleide_Taster network: connected
2019-05-27_19:30:03 Ankleide_Taster on
Die Probleme treten immer dann auf, wenn das DOIF etwas abfragt. Also z. B. wenn ich die Ankleide betrete. In dem Moment schaltet sich die Osram–Leuchte an (d. h. das ,,Licht brennt"), obwohl der Sensor_Ankleide_Schrank nicht auf open, sondern auf close steht. D. h. zu den vorgenannten Zeiten mit den Fehlermeldungen
Ankleide_Taster network: not connected
waren die Zeiten,wo jemand die Ankleide betreten hat.
Kann mir jemand weiterhelfen? [Ich hoffe, ich habe das einigermaßen verständlich geschildert.]
Viele Grüße von Frank und danke an ,pah' für das tolle Modul!
Hallo Frank,
Der besseren Lesbarkeit wegen setze bitte Logs und list Ausgaben in Codetags. Das ist die Raute im Texteditor des Forums.
Grüße
OK, erledigt ;) !
@Cluni: Muss ich sehen, ob ich das irgendwie abfangen kann. Ab Dienstag wieder, bis dahin wegen 2 BMBF-Deadlines "Land unter".
@Benni: Sehr schön, habe das auch mit readingsProxy gelöst. Geplant ist, solche Proxies durch das Modul selbst anlegen zu lassen.
@hauenschild: Das Abfrageintervall von 10 Sekunden ist zu kurz, die Latenz der Shellys bei den Antworten spielt hier eine Rolle. Macht auch bei den neuen Rückmeldemöglichkeiten nicht wirklich Sinn, würd eich auf 60 Sekunden hochsetzen.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 28 Mai 2019, 04:14:34
@Cluni: Muss ich sehen, ob ich das irgendwie abfangen kann. Ab Dienstag wieder, bis dahin wegen 2 BMBF-Deadlines "Land unter".
Keine Panik - das ist ja nichts lebensbedrohendes und schließlich ist das alles hier ja mehr oder weniger Hobby und läuft nebenbei. Beim Skript für die Rollladensteuerung war das damals ja auch nicht anders. Daher bin ich auch recht froh, dass Marko aka Cooltux sich der "Modulifizierung" der Rollladensteuerung angenommen hat. Das hätte ich zeitlich nicht so schnell hinbekommen... ;)
@pah
nur ne kleinigkeit - mal wieder die cref :)
der link https://commandref.fhem.de/commandref_DE.html#Shelly in die deutsche commandref funktioniert nicht richtig. ich weiß das du aktiv eh nur die englische schreibst, aber falls jemand die übersicht am anfang der cref vor sich hat und zum shelly teil "springen" möchte geht das leider nicht.
wenn ich es richtig sehe fehlt der anker für den link?!
@Benni: Übrigens ist es viel besser, für die setFn einfach {$CMD." 0"} zu verwenden - dann funktionieren alle SetExtensions...
LG
pah
Danke Pah!
Ich habe das bei mir umgestellt und auch den Post angepasst.
gb#
Ich habe mir schon wieder was praktisches zum Shelly dazugebastelt. ;D
Ich habe mir ein mir ein userreading erstellt, in dem ein Link auf das webUI des Shellys zur Verfügung gestellt wird. Damit kann ich dann direkt aus der Detailansicht des Devices in FHEMWEB auf die Shelly-Weboberfläche springen:
Dazu ein userreading mit folgendem Inhalt:
webUI:.* {ShellyUI($NAME)}
Und die darin aufgerufene Funktion in der 99_myUtils.pm:
sub ShellyUI($) {
my ($name)=@_;
my $tcpip=InternalVal($name,'TCPIP',undef);
return '<html><a href="http://'.$tcpip.'">Shelly\'s WebUI</a></html>' if defined($tcpip);
return 'unknown';
}
Zurückgegeben wird ein HTML-Link (a href), eingebettet in <html>-Tags. Dies wird bei Readings im FHEMWEB vor der Anzeige entsprechend umgesetzt, so dass hier ein funktionierender Link im Reading angezeigt wird (s. Screenshot).
Hinweis für alle ungeduldigen: Die Auswertung des Userreadings erfolgt natürlich erst, wenn (irgend-)ein Event beim Shelly-Device eintrudelt.
@Pah: Den Link könnte man evtl. auch direkt in die Anzeige von TCPIP in FHEMWEB einbauen ;)
gb#
Hallo
könnte bitte jemand ein Beispiel einer Shelly RGBW2 Definition einstellen ? Bevorzugt über HTTP - MQTT ginge auch..
Danke und Grüße
Vielen Dank pah! Ich habe das Abfrageintervall auf 60 Sekunden gesetzt:
interval 60
Jetzt funktioniert es einwandfrei.
Zitatkönnte bitte jemand ein Beispiel einer Shelly RGBW2 Definition einstellen ?
Was ist denn daran unklar ? Wenn das Teil im color-Modus ist natürlich
define WZ.Strip Shelly 192.168.0.180
attr WZ.Strip model shellyrgbw
attr WZ.Strip mode color
Das steht auch so in der CommandRef dazu - man muss sie nur
l - e - s - e - nUnd wer es komfortabler möchte, setzt noch
attr WZ.Strip stateFormat rgb
attr WZ.Strip WebCmd rgb:rgb ff0000:rgb 98FF23:rgb 0000ff:on:off
LG
pah
Habe gerade die Version 2.02 eingecheckt, mit einigen Fixes in der CommandRef und der Umsetzung des Vorschlags von Benni. Geht aber nicht bei Internals, sondern nur bei Readings
LG
pah
Guten Morgen zusammen,
erstmal Danke an pah für das Modul!
Ich habe es mit einem Shelly 2 im Einsatz. Der Shelly 2 hat die Firmware v1.5.0-hotfix2 und das Modul die Version 2.01. Da ich auf meiner Testinstanz etwas ausprobieren wollte, habe ich den Shelly dort neu angelegt. Das habe ich gemacht:
- define Shelly01 Shelly <IP address>
- attr Shelly01 model shelly2
- attr Shelly01 mode relay
Das führte zur Meldung
Shelly01: unknown attribute mode. Type 'attr Shelly01 ?' for a detailed list. Set-Befehle werden dann auch nicht verarbeitet. In der fhem GUI ist der komplette Block für die set-Befehle verschwunden.
Die Reihenfolge die allerdings funktioniert ist:
- define Shelly01 Shelly <IP address>
- attr Shelly01 mode relay
- attr Shelly01 model shelly2
Dann ist alles so, wie es sein soll. Falls das nicht ein lokales Problem bei mir ist (kann man ja nie ausschließen), wäre es schön, wenn auch der erste Weg, den ich versucht habe funktionieren würde.
Hallo
@PAH - Danke für das Beispiel und die Arbeit am Modul!
Ich habe ich Command Ref natürlich gelesen und seit einiger Zeit den Fehler von MarNei vorliegen. Ich dachte aber - der Fehler sitzt vor der Tastatur.... Nun zweifle ich etwas weniger an mir... .
define SHL_RGB_Stripes Shelly 192.168.178.75
attr SHL_RGB_Stripes model shellyrgbw
attr SHL_RGB_Stripes mode color
attr SHL_RGB_Stripes stateFormat rgb
attr SHL_RGB_Stripes WebCmd rgb:rgb ff0000:rgb 98FF23:rgb 0000ff:on:off
führt zu: SHL_RGB_Stripes: unknown attribute mode. Type 'attr SHL_RGB_Stripes ?' for a detailed list. SHL_RGB_Stripes: unknown attribute WebCmd. Type 'attr SHL_RGB_Stripes ?' for a detailed list.
Ein
define SHL_RGB_Stripes Shelly 192.168.178.75
attr SHL_RGB_Stripes mode color
attr SHL_RGB_Stripes model shellyrgbw
attr SHL_RGB_Stripes stateFormat rgb
attr SHL_RGB_Stripes WebCmd rgb:rgb ff0000:rgb 98FF23:rgb 0000ff:on:off
attr SHL_RGB_Stripes room Shelly
führt nur zu SHL_RGB_Stripes: unknown attribute WebCmd. Type 'attr SHL_RGB_Stripes ?' for a detailed list.
On-off ist möglich RGB settings funktionieren nicht
FW Modul v1.5.0-hotfix2
Danke und Grüße,
Mark
Bei mir ist das Attribut ,,mode" auch nicht verfügbar wenn model=shellyrgbw gestzt ist.
Der Workaround von @MarNei funktioniert aber: zuerst mode setzen, danach model
Ist in der aktuellen Version gefixt.
Es hilft auch, wenn man einfach noch einmal das Attribut "model" setzt - der Fehler tritt nur bei der ersten Definition auf.
LG
pah
Nur kurze Rückmeldung zur aktuellen Version (keine Ahnung, ob du daran schon was angepackt hattest - soll also keine Kritik oder ein Drängen sein): der Error im state nach dem Neustart von fhem ist noch da. Nach einem get status ist alles wieder ok.
Gesendet von iPhone XR mit Tapatalk
Zitatkeine Ahnung, ob du daran schon was angepackt hattest
Nö. Kann mit dem Startverhalten anderer FHEM-Komponenfen zusammenhängen.
LG
pah
Habe gerade Version 2.03 eingecheckt - mit ein paar Fixes beim Setzen der Konfiguration.
Es geht z.B.jetzt auch
set ... config effect 0|..|6
LG
pah
Moin,
Ich habe vor ein paar Tagen das Shelly Modul geupdatet. Ich nutze den Shelly 1 mit der Firmwar v1.5.0-hotfix2.
Seit dem Update des Moduls taucht im Log ständig die Fehlermeldung im Screenshot auf.
Ich habe gesehen, dass hier im Thread bereits im Januar über die Fehlermeldung gesprochen wurde. Ich konnte aber aus den Antworten für mein Problem nicht schlau werden bzw. habe einige Lösungsansätze ausprobiert.
Für jeden Hinweis wäre ich sehr dankbar :)
Ergänzung:
Es betrifft die lines: 844 und 890 im Shelly Modul
CHANGED
DEF 192.168.xxx.xxx
DURATION 0
FUUID 5cfa38dd-f33f-7013-7c94-964fb1ed968f31e0
INTERVAL 60
NAME SZ_mainlamp
NR 57
STATE off
TCPIP 192.168.xxx.xxx
TYPE Shelly
READINGS:
2019-06-07 12:17:17 cloud disabled
2019-06-07 12:17:17 firmware v1.5.0-hotfix2
2019-06-07 13:07:00 network <html>connected to <a href="http://192.168.xxx.xxx">192.168.xxx.xxx</a></html>
2019-06-07 13:12:28 relay off
2019-06-07 13:12:28 state off
Attributes:
interval 60
model shelly1
shellyuser xy
Liebe Grüße meyerhavener
Hallo,
hat von Euch einer neuere Informationen, ob die Shelly-Software auch bald den Status senden kann, wenn der Roller-Mode eingestellt ist?
Ich verwende das Modul AutoShuttersControl und das wird verwirrt dadurch, dass der richtige Status erst nach einem neuem Polling vorhanden ist.
Oder kann man das Polling unabhängig vom Interval kurz nach einem Fahrbefehl anstossen?
Nach einem von FHEM gesendeten Fahrbefehl ist der Status automatisch richtig - nur manuelle Änderungen des Standes am Rolladenaktor selbst werden erst nach einem Polling erkannt.
LG
pah
Hallo pah,
so habe ich es auch verstanden, aber wie im debug-log gezeigt, kommen verschiedene Werte.
ASC_DEBUG!!! 2019.06.11 10:41:51 - EventProcessingBrightness: Sh_S - Event von einem Helligkeitssensor erkannt. Verarbeitung läuft. Sollten keine weitere Meldungen aus der Funktion kommen, so befindet sich die aktuelle Zeit nicht innerhalb der Verarbeitungszeit für Sunset oder Sunrise
ASC_DEBUG!!! 2019.06.11 10:41:51 - EventProcessingShadingBrightness: Sh_S - Es wird nun geprüft ob der übergebene Event ein nummerischer Wert vom Brightnessreading ist.
ASC_DEBUG!!! 2019.06.11 10:41:51 - EventProcessingShadingBrightness: Sh_S - Nummerischer Brightness-Wert wurde erkannt. Der Wert ist: 925.0 RainProtection: unprotected WindProtection: unprotected
ASC_DEBUG!!! 2019.06.11 10:41:51 - ShadingProcessing: Sh_S - Übergebende Werte - Azimuth:115.15, Elevation: 49.04, Brightness: 925.0, OutTemp: 16.8, Fenster Position: 125, Winkel Links: 10, Winkel Rechts: 10, Ist es nach der Zeitblockadezeit: JA, Ist es nach der manuellen Blockadezeit: JA, Ist es nach der Hälfte der Beschattungswartezeit: JA
ASC_DEBUG!!! 2019.06.11 10:41:51 - ShadingProcessing: Sh_S - Alle Werte für die weitere Verarbeitung sind korrekt vorhanden und es wird nun mit der Beschattungsverarbeitung begonnen
ASC_DEBUG!!! 2019.06.11 10:41:51 - ShadingProcessing: Sh_S - Alle Beschattungsbedingungen wurden erfüllt und somit wird der Beschattungsstatus um eine Stufe angehoben. Alter Status: in reserved Neuer Status: in
ASC_DEBUG!!! 2019.06.11 10:41:51 - FnSetCmdFn: Sh_S - Rolllo wird gefahren, aktuelle Position: 100, Zielposition: 10. Grund der Fahrt: shading in
ASC_DEBUG!!! 2019.06.11 10:41:51 - FnSetDriveCmd: Sh_S - NICHT versetztes fahren
ASC_DEBUG!!! 2019.06.11 10:41:51 - FnSetDriveCmd: Sh_S - NoOffset: NEIN
ASC_DEBUG!!! 2019.06.11 10:41:51 - FnShuttersCommandSet: Sh_S - Das Rollo wird gefahren. Kein Partymodus aktiv und das zugordnete Fenster ist entweder nicht offen oder keine Terassentür
ASC_DEBUG!!! 2019.06.11 10:41:51 - ShadingProcessing: Sh_S - Der aktuelle Beschattungsstatus ist: in und somit wird nun in die Position: 10 zum Beschatten gefahren
ASC_DEBUG!!! 2019.06.11 10:41:51 - ShadingProcessing: Sh_S - Der aktuelle Beschattungsstatus ist: in, Beschattungsstatus Zeitstempel: 2019.06.11 10:41:51
ASC_DEBUG!!! 2019.06.11 10:41:51 - EventProcessingShadingBrightness: Sh_S - Alle Bedingungen zur weiteren Beschattungsverarbeitung sind erfüllt. Es wird nun die eigentliche Beschattungsfunktion aufgerufen
ASC_DEBUG!!! 2019.06.11 10:41:51 - EventProcessingShutters: Sh_S - Event vom Rolllo erkannt. Es wird nun eine etwaige manuelle Fahrt ausgewertet. Int von gettimeofday: 1560242511 Last Position Timestamp: 1560242511 Drive Up Max Duration: 60 Last Position: 100 aktuelle Position: 10
ASC_DEBUG!!! 2019.06.11 10:41:51 - EventProcessingShutters: eine automatisierte Fahrt durch ASC wurde erkannt! Es werden nun die LastDriveReading und StateReading Werte gesetzt!
ASC_DEBUG!!! 2019.06.11 10:42:05 - EventProcessingShutters: Sh_S - Event vom Rolllo erkannt. Es wird nun eine etwaige manuelle Fahrt ausgewertet. Int von gettimeofday: 1560242525 Last Position Timestamp: 1560242511 Drive Up Max Duration: 60 Last Position: 100 aktuelle Position: 100
ASC_DEBUG!!! 2019.06.11 10:42:05 - EventProcessingShutters: eine automatisierte Fahrt durch ASC wurde erkannt! Es werden nun die LastDriveReading und StateReading Werte gesetzt!
ASC_DEBUG!!! 2019.06.11 10:43:06 - EventProcessingShutters: Sh_S - Event vom Rolllo erkannt. Es wird nun eine etwaige manuelle Fahrt ausgewertet. Int von gettimeofday: 1560242586 Last Position Timestamp: 1560242511 Drive Up Max Duration: 60 Last Position: 100 aktuelle Position: 5
ASC_DEBUG!!! 2019.06.11 10:43:06 - EventProcessingShutters: eine manualle Fahrt wurde erkannt!
ASC_DEBUG!!! 2019.06.11 10:44:36 - EventProcessingTwilightDevice: Sh_S - Event vom Astro oder Twilight Device wurde erkannt. Event wird verarbeitet
Um 10:41:51 wird die Fahrt ausgelöst und die Position 10 gesetzt.
Um 19:42:05 wird die Position wieder auf 100 gesetzt und dann nach weitern 60 Sekunden kommt die Position 5.
Das kann ich mir nicht erklären.
Ich bin aber nicht der Maintainer von ASC.
LG
pah
Hallo pah,
das ist mir klar.
Da aber der Rolladen im Shelly-Modul betrieben wird und dieser Modul dem ASC irgendwelche Fahrten meldet, habe ich es hier versucht zu klären.
Trotzdem vielen Dank.
cu
Walter
Sorry, aber das ist nicht korrekt - dieses Modul meldet gar nichts an ASC, sondern setzt nur seine eigenen Readings. Dieser Unterschied ist wesentlich für die Fehlersuche, da darf man also bitte keine Nebelkerzen zünden.
LG
pah
Hallo pah,
ich will keine Nebelkerzen zünden, sondern ich frage nur höflich weil ich etwas lernen will.
Die Unterstützung hier finde ich toll.
Zur weiteren Eingrenzung meines Problems habe ich einen neuen Shelly angelegt und ASC weggelassen.
Keine weiteren Gimmicks.
defmod Sh_Test Shelly 172.16.5.26
attr Sh_Test interval 60
attr Sh_Test mode roller
attr Sh_Test model shelly2.5
attr Sh_Test room Rolladen
attr Sh_Test verbose 5
setstate Sh_Test stopped
setstate Sh_Test 2019-06-13 12:28:20 cloud disabled
setstate Sh_Test 2019-06-13 12:29:00 config mode=roller [channel s]
setstate Sh_Test 2019-06-13 12:41:04 energy_0 5.6
setstate Sh_Test 2019-06-13 12:28:20 firmware v1.5.0-hotfix2
setstate Sh_Test 2019-06-13 12:42:04 last_dir up
setstate Sh_Test 2019-06-13 12:28:20 network <html>connected to <a href="http://172.16.5.26">172.16.5.26</a></html>
setstate Sh_Test 2019-06-13 12:42:04 pct 100
setstate Sh_Test 2019-06-13 12:42:04 position open
setstate Sh_Test 2019-06-13 12:42:04 power 0
setstate Sh_Test 2019-06-13 12:41:04 power_0 157.67
setstate Sh_Test 2019-06-13 12:42:04 state stopped
setstate Sh_Test 2019-06-13 12:29:21 stop_reason normal
Dann habe ich im Modul Fahrbewegungen ausgelöst und im Eventlog verfolgt.
2019-06-13 12:38:51 Shelly Sh_Test closed
2019-06-13 12:38:51 Shelly Sh_Test moving_down
2019-06-13 12:38:51 Shelly Sh_Test pct: 0
2019-06-13 12:38:51 Shelly Sh_Test position: closed
2019-06-13 12:38:53 Shelly Sh_Test power_0: 0
2019-06-13 12:38:53 Shelly Sh_Test energy_0: 5.6
2019-06-13 12:38:53 Shelly Sh_Test pct: 100
2019-06-13 12:38:53 Shelly Sh_Test position: open
2019-06-13 12:38:53 Shelly Sh_Test power: 161.5
2019-06-13 12:39:53 Shelly Sh_Test stopped
2019-06-13 12:39:53 Shelly Sh_Test pct: 0
2019-06-13 12:39:53 Shelly Sh_Test position: closed
2019-06-13 12:39:53 Shelly Sh_Test power: 0
2019-06-13 12:39:53 Shelly Sh_Test last_dir: down
2019-06-13 12:41:03 Shelly Sh_Test open
2019-06-13 12:41:03 Shelly Sh_Test moving_up
2019-06-13 12:41:03 Shelly Sh_Test pct: 100
2019-06-13 12:41:03 Shelly Sh_Test position: open
2019-06-13 12:41:04 Shelly Sh_Test pct: 0
2019-06-13 12:41:04 Shelly Sh_Test position: closed
2019-06-13 12:41:04 Shelly Sh_Test power: 157.67
2019-06-13 12:41:04 Shelly Sh_Test power_0: 157.67
2019-06-13 12:41:04 Shelly Sh_Test energy_0: 5.6
2019-06-13 12:42:04 Shelly Sh_Test stopped
2019-06-13 12:42:04 Shelly Sh_Test pct: 100
2019-06-13 12:42:04 Shelly Sh_Test position: open
2019-06-13 12:42:04 Shelly Sh_Test power: 0
2019-06-13 12:42:04 Shelly Sh_Test last_dir: up
Auch hier bekomme ich die für mich verwirrenden Stati.
Eine bis zwei Sekunden nach dem Fahrbefehl kommt wieder der alte Status und dann nach Ablauf des Intervals durch das Polling der richtige Status.
Hmmm. Einen 2.5er habe ich nicht, beim 2er tritt so etwas nicht auf. Das kann mit der notwendigen 2. Strommessung im 2.5er zu tun haben.
In Zeile 1208 des Modul steht
InternalTimer(gettimeofday()+1, "Shelly_updown2", $hash,1);
Bitte mal diesen Code in
InternalTimer(gettimeofday()+2, "Shelly_updown2", $hash,1);
ändern und testen.
LG
pah
P.S.: Man glaubt es nicht, aber die Mehrzahl von Status heißt nicht Stati.
Die Änderung hat nichts gebracht.
2019-06-13 13:41:00 Shelly Sh_Test closed
2019-06-13 13:41:00 Shelly Sh_Test moving_down
2019-06-13 13:41:00 Shelly Sh_Test pct: 0
2019-06-13 13:41:00 Shelly Sh_Test position: closed
2019-06-13 13:41:02 Shelly Sh_Test pct: 100
2019-06-13 13:41:02 Shelly Sh_Test position: open
2019-06-13 13:41:02 Shelly Sh_Test power: 169.19
2019-06-13 13:41:02 Shelly Sh_Test power_0: 0
2019-06-13 13:41:02 Shelly Sh_Test energy_0: 6.5
2019-06-13 13:42:03 Shelly Sh_Test stopped
2019-06-13 13:42:03 Shelly Sh_Test pct: 0
2019-06-13 13:42:03 Shelly Sh_Test position: closed
2019-06-13 13:42:03 Shelly Sh_Test power: 0
2019-06-13 13:42:03 Shelly Sh_Test last_dir: down
Ich teste es jetzt an einen Shelly 2
Auch an meinem Shelly 2 verhält es sich genauso.
2019-06-13 13:57:05 Shelly Sh_Test open
2019-06-13 13:57:05 Shelly Sh_Test moving_up
2019-06-13 13:57:05 Shelly Sh_Test pct: 100
2019-06-13 13:57:05 Shelly Sh_Test position: open
2019-06-13 13:57:07 Shelly Sh_Test pct: 0
2019-06-13 13:57:07 Shelly Sh_Test position: closed
2019-06-13 13:57:07 Shelly Sh_Test power: 166.12
2019-06-13 13:57:07 Shelly Sh_Test power: 166.12
2019-06-13 13:57:07 Shelly Sh_Test energy: 5.8
2019-06-13 13:58:07 Shelly Sh_Test stopped
2019-06-13 13:58:07 Shelly Sh_Test pct: 100
2019-06-13 13:58:07 Shelly Sh_Test position: open
2019-06-13 13:58:07 Shelly Sh_Test power: 0
2019-06-13 13:58:07 Shelly Sh_Test last_dir: up
Und die raw definition:
defmod Sh_Test Shelly 172.16.5.25
attr Sh_Test interval 60
attr Sh_Test mode roller
attr Sh_Test model shelly2
attr Sh_Test room Rolladen
attr Sh_Test verbose 5
setstate Sh_Test stopped
setstate Sh_Test 2019-06-13 13:53:59 cloud disabled
setstate Sh_Test 2019-06-13 13:54:27 config mode=roller [channel s]
setstate Sh_Test 2019-06-13 13:57:07 energy 5.8
setstate Sh_Test 2019-06-13 13:53:59 firmware v1.5.0-hotfix2
setstate Sh_Test 2019-06-13 13:58:07 last_dir up
setstate Sh_Test 2019-06-13 13:53:59 network <html>connected to <a href="http://172.16.5.25">172.16.5.25</a></html>
setstate Sh_Test 2019-06-13 13:58:07 pct 100
setstate Sh_Test 2019-06-13 13:58:07 position open
setstate Sh_Test 2019-06-13 13:58:07 power 0
setstate Sh_Test 2019-06-13 13:58:07 state stopped
setstate Sh_Test 2019-06-13 13:55:54 stop_reason normal
Ich habe zum Test einmal die Zeile 1208 ganz auskommentiert, da mich im Moment die Leistungsmessung nicht interessiert.
Wenn dann nicht zufällig das von Interval ausgelöste Polling dazwischen kommt, habe ich das von mir gewünschte Verhalten.
2019-06-14 11:10:45 Shelly Sh_Kb open
2019-06-14 11:10:45 Shelly Sh_Kb moving_up
2019-06-14 11:10:45 Shelly Sh_Kb pct: 100
2019-06-14 11:10:45 Shelly Sh_Kb position: open
2019-06-14 11:10:59 Shelly Sh_Kb stopped
2019-06-14 11:10:59 Shelly Sh_Kb last_dir: up
Kommt das Polling während der Fahrt dazwischen, gibt Shelly die aktuelle Position richtig zurück, was für mich nur verwirrend ist.
Wäre es nicht besser, während der Fahrtzeit (vom Start bis zu maxtime) das Polling zu unterdrücken?
Beim shellyrgbw gibt es das Reading rgb. Wenn der Hex Wert für eine Farbe auf 0, also aus ist, wird in dem Reading nur eine 0, anstatt zwei Nullen angezeigt Da FTUI einen 6 stelligen Wert benötigt, funktioniert das nicht. Gibt es die Möglichkeit ohne Userreading das umzustellen?
z.B. ist blau 00FF anstatt 0000FF und grün 0FF0 anstatt 00FF00
Nehm ich mal auf.
Habe aber gerade etwas viel um die Ohren.
LG
pah
Edit: Patch: Zeile 996 ändern in my $rgb = sprintf("%02X%02X%02X", $red,$green,$blue);
LG
pah
Zitat von: Prof. Dr. Peter Henning--> https://forum.fhem.de/index.php/topic,100782.msg942344.html#msg942344 (https://forum.fhem.de/index.php/topic,100782.msg942344.html#msg942344)
Tipp:
Mit der aktuellen Firmware 1.5 lassen sich die Shelly 1, 1PM, 2 und 2.5 so konfigurieren, dass sie beim Schließen und Öffnen der Eingangsschaltkanäle jeweils eine bestimmte URL aufrufen. Mit anderen Worten: Damit lassen sich beliebige Lichtschalter oder -taster mit einem konkurrenzlos günstigen IP-Tastensensor ausstatten, um etwas in FHEM zu steuern. Dafür braucht man weder einen Cloud-Zugang, noch das MQTT-Protokoll - es tut das einfache Shelly-Modul.
LG
pah
Hallo zusammen, hallo pah,
sorry für die unkonventionelle Zitatverlinkung, aber ich konnte mir nicht anders helfen, da der o.g. Threat nicht zum Antworten aktiviert ist und ich die Lösung auf meine Frage nach einem Beispiel nirgends gefunden habe.
zum Thema: Kann mir jemand ein Beispiel nennen, wie der Link lauten muss um bspw. in Fhem ein Licht anzuschalten, oder einen Link nennen, worunter ich Beispiele finden kann?
Vielen Dank vorab!
VG,
al
Zitat von: justcallmeal am 17 Juni 2019, 13:35:46
Kann mir jemand ein Beispiel nennen, einen Link nennen, worunter ich Beispiele finden kann?
Wer Geduld hat, suchen und lesen kann, ist im Vorteil:
https://fhem.de/commandref.html#Shelly (https://fhem.de/commandref.html#Shelly) ;)
Zu der Doku habe ich nochmal eine Frage an pah
Es gibt button_on/off und out_on/off, was bewirkt das in dem Shelly Modul ?
Ich habe vor den detached Mode zu verwenden, wobei dann alle vier URL belegt wären wie in der Doku beschrieben.
Es ergibt sich dann aber ein Status für den Schalter und ein zweiter Status für den Ausgang. In welchem readings finde ich diese Status jeweils ?
Das sind die direkten Ruckmeldungen vom shelly. Einmal für den Schaltereingang an/aus und einmal für den Zustand des Relais an/aus....
Dadurch bekommt fhem direkt mit, wenn sich lokal am shelly etwas ändert. Ohne zu pollen.
Gesendet von iPhone XR mit Tapatalk
Danke Cluni für die schnelle Antwort, aber wie kann ich beide informationen in FHEM weiterverwenden für eigene Zwecke, da gibt es doch sicher mehrere Readings, wenn ja welche ?
Zitat von: bombardi am 18 Juni 2019, 17:14:54
aber wie kann ich beide informationen in FHEM weiterverwenden
Lies mal ein paar Seiten vorher (ab 16 meine ich) und dann die commandref, steht alles drin.
P.S.: ein Blick herein (https://www.shelly-support.eu) lohnt sich auch, da werden diese Funktionen auch nochmal beschrieben
Ich formuliere es nochmal anders.
Ich verwende zur Zeit in allen meinen Shelly 1 und 2 nur die URL out_on und out_off, damit bekomme ich immer sofort die Änderung am Ausgang mit weil sich der State im FHEM-device direkt ändert.
Wenn ich jetzt aber bei einem Shelly den detached mode verwende und für den Schalter zusätzlich die URL'S mit but_on und but_off, wie in der commandref beschrieben, verwende, erwarte ich das sich das nicht auch im State wiederspiegelt sondern in einem anderen reading.
Sonst macht die Unterscheidung keinen Sinn.
Ich kann natürlich auch ein zweites Device auf den gleichen Shelly setzen und die URL nur für die Eingänge entsprechend anpassen, aber dann brauchte man die Unterscheidung but und out auch nicht mehr.
Bitte geht auf meine Frage ein und verweist nicht nur auf die Commandref, die ich glaube verstanden zuhaben oder auf ein weiteres Forum, in dem ich ebenfalls aktiv bin ohne konkretere Verlinkung.
Was kann man noch tun, als "alles hinzuschreiben" und dann noch zu sagen "steht alles drin"? Nachhilfe geben?
pah
Hallo pah,
in welchem Reading landet den nun die Änderung der Schalterzustände wenn man die URL mit But_on und But_off verwendet ?
Diese Frage stelle ich die ganze Zeit und dazu steht nichts in der Commandref und es wurde im Forum nach 16 nur beschrieben, das dies in deinem Modul intern umgesetzt wird
(Auszug aus Antwort #267 am: 25 Mai 2019, 10:33:41 von Benni:Der Shelly schickt über die URL den entsprechenden trigger (Event) an das Shelly-Device in FHEM. Die Ereignisbehandlung des Events wird vom Shelly-Device in FHEM ab Modulversion 2.0.0 implizit übernommen.).
Also ich wiederhole nochmal, ich habe verstanden und es funktioniert auch bei mir, wenn ich in der URL für die Ausgänge
For Output switched ON url: http://<FHEM IP address>:<Port>/fhem?XHR=1&cmd=set%20<Devicename>%20out_on%20[<channel>]
For Output switched OFF url: http://<FHEM IP address>:<Port>/fhem?XHR=1&cmd=set%20<Devicename>%20out_off%20[<channel>]
+ Token und login etc. Eintrage
ändert sich der Status im FHEM in dem Moment wo der Ausgang nach ein oder aus wechselt sofort mit.
Ich möchte jetzt bei einem Shelly der im detached mode betrieben wird zusätzlich die anderen beiden URL verwenden
For Button switched ON url: http://<FHEM IP address>:<Port>/fhem?XHR=1&cmd=set%20<Devicename>%20button_on%20[<channel>]
For Button switched OFF url: http://<FHEM IP address>:<Port>/fhem?XHR=1&cmd=set%20<Devicename>%20button_off%20[<channel>]
+ Token und login etc.
um die Schalterstellung genau so schnell zur Verfügung zu haben.
Diese wird so hoffe ich in einem weiteren Reading bereitgestellt auf dessen Wechsel ich reagieren möchte.
Ist das möglich und wenn ja, wie hast du das Reading genannt oder muss ich die Lösung aus meinem letzten Post verwenden und ein zweites Device erstellen.
Die entsprechenden Readings heißen "button" und "relay" - siehe Anhang
Hier sieht man auch schön, dass diese unabhängig von einander sind. An dem Shelly habe ich eine Kreuzschaltung am Eingang. Der Eingang ist momentan auf on. Ausgeschaltet habe ich ca. zwei Minuten später über Apple Home + Homebridge + Fhem...
PS: Hier hatte ich bereits geschrieben, wie der Befehl inkl. Username, Passwort und csrf-Token aussehen muss:
https://forum.fhem.de/index.php/topic,93251.msg942525.html#msg942525
Gepriesen sei Cluni der Newbyversteher. ;D
Du hast es geschafft mir eine einfache Antwort auf die zuerst gestellte Frage zu geben.
Die ist kurz und treffend.
p.s. Auch aus deinem verlinkten Beitrag kann ich nichts über die readings button und relay herauslesen.
Zitat von: bombardi am 19 Juni 2019, 08:55:44
p.s. Auch aus deinem verlinkten Beitrag kann ich nichts über die readings button und relay herauslesen.
Na, wenn wir mal ehrlich sind, dann ist das erstens einigermaßen selbsterklärend und zweitens macht Versuch klug - spätestens nachdem man die Links im Shelly eingefügt hat sieht man ja die Änderungen der Readings.... 8)
Hallo,
wollte gerade meinen ShellyPlug mit einem PW versehen, dann war Sendepause.
In der Doku das hier gefunden:
attr <name> shellyuser <shellyuser>
username for addressing the Shelly web interface
Nun aber noch das PW, wie bekomme ich das rein?
Würde mich über einen Wink mit dem Zaunpfahl freuen.
Grüße Peter
Per Set Commando im Shelly
siehe Anhang
Hallo,
Danke!
Grüße Peter
@bombardi: Nett gemeint, aber bitte für so etwas keinen Screenshot verwenden, eine Textzeile hätte gereicht.
LG
pah
Hallo pah,
laut API stellt der PlugS seine interne Temperatur im Status zur Verfügung, kannst du diese bitte als Reading bereitstellen.
Mir ist bewusst, das diese bei angezogenem Relais zu hoch ist, aber die Differenz kann man mit einer Messreihe bestimmen und sich den Wert selbst korrigieren.
Zitatkannst du diese bitte als Reading bereitstellen.
Derzeit nicht geplant.
LG
pah
Hallo, nach einem Neustart von FHEM bekomme ich folgende Meldung im Log:
2019.07.04 09:23:12 1: [Shelly_status] invalid JSON data
2019.07.04 09:23:12 1: [Shelly_status] invalid JSON data
2019.07.04 09:23:12 1: [Shelly_status] invalid JSON data
2019.07.04 09:23:12 1: [Shelly_status] invalid JSON data
glaube nicht das es mit dem neustart zusammenhängt.... oder war es mehr als das, also vorher update o.ä.
ansonsten setz mal dein verbose level auf 5 für das shelly device, und dann nochmal den auszug davon hier posten.
Hallo,
verbose 5 zeigt dann:
2019.07.04 09:54:11 1: [Shelly_status] invalid JSON data
2019.07.04 09:54:11 5: [Shelly_status] has obtained data 401 UnauthorizedDamit die Shellys laufen, mußte ich in meiner "FHEM Neustart" Routine die Shellys einmal "STOP" senden.
global:INITIALIZED ;sleep 60; set D_Kalender_Reload on;sleep 60;set Cams_Live on;sleep 2; set Jalo_EG_1 stop;set Jalo_EG_2 stop;set Jalo_EG_3 stop; set Jalo_OG stopdann stehen diese nach einem Neustart nicht mehr auf "Error"
Werde aber zusätzlich mal das Passwort bei den Shellys raus nehmen.
Hat in Post
ZitatAntwort #235
auch nach einem Neustart zu fehlern geführt.
Zitat von: THZ_Haus am 04 Juli 2019, 10:00:02
verbose 5 zeigt dann:
2019.07.04 09:54:11 1: [Shelly_status] invalid JSON data
2019.07.04 09:54:11 5: [Shelly_status] has obtained data 401 Unauthorized
kommt da noch mehr?? davor?
Zitat von: THZ_Haus am 04 Juli 2019, 10:00:02
Damit die Shellys laufen, mußte ich in meiner "FHEM Neustart" Routine die Shellys einmal "STOP" senden.
global:INITIALIZED ;sleep 60; set D_Kalender_Reload on;sleep 60;set Cams_Live on;sleep 2; set Jalo_EG_1 stop;set Jalo_EG_2 stop;set Jalo_EG_3 stop; set Jalo_OG stop
dann stehen diese nach einem Neustart nicht mehr auf "Error"
das sie auf error stehen, kommt von den nicht korrekten Werten...
und welchen befehlt du sendest, sollte egal sein. damit wird nur der status neu gesetzt. bei rollos macht da stop natürlich sinn ;)
Zitat von: THZ_Haus am 04 Juli 2019, 10:00:02
Werde aber zusätzlich mal das Passwort bei den Shellys raus nehmen.
Hat in Post auch nach einem Neustart zu fehlern geführt.
ok, kannste mal versuchen.
evtl. hat pah aber noch ne idee (habe nicht alle antworten in diesem thread gelesen).
Das nach dem Neustart die Zustände nicht gelesen werden ist mir gestern auch wieder einmal aufgefallen.
Ich habe eine Plug S an der Waschmaschine mit dem ich über die Leistungserfassung eine Meldung generiere wenn die Maschine fertig ist.
Das hat nach einem Neustart am Sonntag gestern nicht funktioniert.
Beim untersuchen der Ursache habe ich festgestellt, das der State error ist und als ich dem eingeschalteten Plug ein ON geschickt habe bekam ich wieder Werte und der State war OK.
Einfach abwarten, bis der erste Status geholt worden ist - oder nicht so häufig neustarten...
LG
pah
Sorry pah,
aber 3 Tage warten sollten reichen und der Status war immer noch error, mit einem 3 Tage alten Zeitstempel.
Ich starte mein FHEM grundsätzlich nur wenn nötig.
Aber ich mache halte auch regelmäßig updates um aktuell zu bleiben
Das ist auch bei mir so....
Gesendet von iPhone XR mit Tapatalk
Zitat von: bombardi am 05 Juli 2019, 07:44:33
aber 3 Tage warten sollten reichen und der Status war immer noch error, mit einem 3 Tage alten Zeitstempel.
mmmmh, also wenn ich den code richtig deute, dann sollte _eigentlich_ immer wieder ein neuer Timer gestartet werden der dann den Status des Shelly entsprechend abruft und dann die readings setzt :o
gibt es logfile ausgaben während der "error"-Status Zeit?
oder ein list? (keine ahnung ob da was zu erkennen wäre)
Sehe ich das richtig, dass das CSRF-Token in den Action URL's nach jedem Neustart von FHEM in den Shelly's aktualisiert werden muss? Oder habe ich da was überlesen?
Edit: Nein muss man nicht -> attr WEB.* csrfToken <beliebige Folge aus Zeichen und Zahlen>
Ich bin immer zu ungeduldig. ;-)
Zitat von: Cluni am 05 Juli 2019, 07:55:42
Das ist auch bei mir so....
Gesendet von iPhone XR mit Tapatalk
Bei mir auch ...
Gesendet von meinem GM1913 mit Tapatalk
Hallo,
ich hab seit ein paar Tagen folgendes im Log stehen
2019.07.09 21:10:25 1: ============> Status in Status model=shellyrgbw mode=color
2019.07.09 21:10:56 1: ============> Status in Status model=shellyrgbw mode=relay
2019.07.09 21:11:25 1: ============> Status in Status model=shellyrgbw mode=color
2019.07.09 21:11:53 1: ============> Status in Status model=shellyrgbw mode=color
2019.07.09 21:11:56 1: ============> Status in Status model=shellyrgbw mode=relay
Das sind extrem viele Einträge und ich weis ehrlich gesagt nicht warum die Einträge erscheinen.
Ich nutze folgende Version myShellyRGBW.version => 2.0beta2
hier ein list von meinem Shelly
Internals:
DEF 192.168.178.104
DURATION 0
FUUID 5d0fe5d1-f33f-c32d-a4e5-c26d6bd4f6b4350e
INTERVAL 60
MOVING stopped
NAME myShellyRGBW
NR 673
STATE on
TCPIP 192.168.178.104:80
TYPE Shelly
READINGS:
2019-07-09 20:33:30 L-blue 0
2019-07-09 20:33:30 L-green 0
2019-07-09 20:33:14 L-red 255
2019-07-09 20:32:44 L-white 255
2019-06-23 22:49:53 cloud disabled
2019-07-09 20:32:32 config mode=color=
2019-06-23 22:49:53 firmware v1.5.0-hotfix2
2019-07-09 21:06:51 network connected
2019-07-09 21:20:01 overpower 0
2019-07-09 21:20:02 power 15.52
2019-07-09 20:33:30 rgb FF00
2019-07-09 21:20:01 state on
Attributes:
mode color
model shellyrgbw
room System
verbose 0
Hallo zusammen,
ich habe das Problem, dass die Verwendung von Modul 36_Shelly.pm scheinbar ursächlich dafür ist, dass mein fhem bei Neustart nicht mehr hochfährt.
Der Grund scheint darin zu liegen, dass nach Aussage von Rudolf König in 36_Shelly.pm vergessen wurde "use HttpUtils;" anzugeben.
@pah: kannst Du das bestätigen, bzw. im Modul nachziehen?
Quellenverweis: https://forum.fhem.de/index.php?topic=102198 (https://forum.fhem.de/index.php?topic=102198)
VG,
al
Ich sags ja ungern, aber da hat Rudi Recht.
Ich habe ein korrigiertes Modul eingecheckt. Damit sollte auch das von Einigen beobachtete "Warten auf Godot" behoben sein, das Modul holt sich eine Minute nach dem Neustart ein Update.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 12 Juli 2019, 08:56:57
Ich habe ein korrigiertes Modul eingecheckt.
Perfekt, jetzt funktioniert auch der Neustart wieder
mit Shelly-Definitionen.
Danke!
VG,
al
Hallo,
ich habe festgestellt das im Modul das Attribut pct100 mit dem Wert closed nicht durchgängig funktioniert.
Als set befehl open close passt es, aber über pct ist keine Umrechnung integriert. Also so scheint es.
Kannst du dir das bitte mal anschauen?
Viele Grüße,
Ulli
Und ich dachte schon, das liegt an mir...
Ähnlicher Effekt...mit einem Shelly 2.5 öffnet und schließt das Rollo mit dem entsprechenden in die Befehlszeile eingegebenen Befehl, aber weder das Modul noch die App registrieren in diesem Fall den Status des Shelly, Rollo fährt aber korrekt.
Bei einem Shelly2 funktioniert es wie es soll. Mit Screenshots schwer zu belegen, da müsste man Videos drehen...
Gruß
Uwe
Ich habe einen 2.5 vor Ort - aber im Moment aus ernsten privaten Gründen etwas wenig Zeit, das zu überprüfen.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 12 Juli 2019, 08:56:57
Ich sags ja ungern, aber da hat Rudi Recht.
Ich habe ein korrigiertes Modul eingecheckt. Damit sollte auch das von Einigen beobachtete "Warten auf Godot" behoben sein, das Modul holt sich eine Minute nach dem Neustart ein Update.
LG
pah
Das kann ich bestätigen, jetzt bekomme ich nach einem Neustart nach kurzer Zeit den aktuellen Status. :)
Habe den pct100 fix selbst gemacht, kannst die ihn einplegen?
Man ersetzt im Set befehl folgende Zeile
$cmd = "?go=to_pos&roller_pos=" . $targetpct;
Durch diese
$cmd = "?go=to_pos&roller_pos=" . ($pctnormal ? $targetpct : 100 - $targetpct);
Danke im Voraus!
Hallo zusammen,
zunächst einmal ein riesiges Dankeschön an alle, die hier so fleißig posten und natürlich an pah für diese grandiose Arbeit. Ich hoffe, dass ich als Newbie eine Frage loswerden darf (und evtl. beantwortet bekomme), auch wenn sie aus Eurer Sicht vielleicht dämlich ist.
Vorab: Ja, ich habe nicht die gesamte Doku von FHEM komplett gelesen und verinnerlicht.
Ich habe bislang noch nicht mit Shelly Devices gearbeitet, liebäugele aber schon länger damit. Meine erste Lieferung ist vor ein paar Tagen angekommen. Ein Shelly1 habe ich auch einigermaßen unfallfrei in Betrieb nehmen können. Jetzt habe ich mich an ein Shelly4pro gewagt und musste feststellen, dass sich das Device erheblich von anderen Multi-Kanal-Geräten unterscheidet. Ich habe auch ein Sonoff 4 zu Hause (und habe es gerade wegen schlechter Verbindung durch das Shelly4pro ersetzt). Das Shelly4pro funktoniert, ich bekomme auch die Kanäle geschaltet mit dem set Befehl, aber alle 4 Kanäle sind in einem Device, so dass ich per "1-klick" eben nur den defchannel geschaltet bekomme. Weiterhin möchte ich an diesen 4-Kanal-Aktor sehr unterschiedliche Abnehmer hängn, die ich auch visuell gerne separat hätte, jedes mit einem eigenen WebCmd schaltbar.
Jetzt kommt der gefährliche Teil meiner Anfrage: Wie lege ich das Ganze so an, dass ich separate Devices habe? Muss/kann ich 4 Devices mit unterschiedlichem Namen unter der gleichen IP anlegen und bei jedem einen anderen defchannel einstellen?
Danke schon einmal im Voraus an alle, die mir bei dieser Anfängerfrage helfen und die Bitte an alle anderen, nicht zu feste zuzuhauen ;-)
Danke und Gruß, Heiko
Hallo Heiko,
lies mal hier im Beitrag « Antwort #273 am: 27 Mai 2019, 18:17:45 »
Danke für die Antwort, Du meintest wahscheinlich den Beitrag 272 von Benni. Den hatte ich auch schon gesehen, aber nicht so ganz verstanden. Aber ich werde mir mal alles, was ich zu den readings proxies finden kann, zu Gemüte führen. Vielleicht bekomme ich es dann ja so hin, wie ich es mir vorstelle.
Danke und Gruß,
Heiko
1. CommandRef lesen
2. set ... xtrachannels ausführen
LG
pah
Zeit für ein Update. Eure Tipps haben mir sehr geholfen. Ich habe mir mit readingsProxy je ein Device für meine Kanäle angelegt bekommen. Auch die Einstellung mit setList und setFn hat funktioniert, so dass ich die Devices wie gewohnt in meinem UI finde. Ich habe auch beim Parent-Device mittels stateFormat hinbekommen, eine Power-Ausgabe zu erzeugen, die mir im Child-Device angezeigt wird. Jestzt aber meine Frage: Bei meinem Device handelt es sich um ein Shelly4pro. Das hat ja 4 Kanäle, somit auch 4 readings für Power (power_*) und 4 readings für den Relais Status (relay_*). Wie bekomme ich es hin, dass mit im jeweiligen readingsProxy-Device das jeweilige Reading für Power des Kanals angezeigt wird?
Vielleicht geht es ja auch gar nicht, aber ich stehe gerade mal wieder wie Ochs vorm Berg.
Idee: Kann ich beim Anlegen des readingsProxy mehr als ein Reading einbinden, etwa so:
define readingsProxyName readingsProxy ParentDeviceName:reading1,reading2
Danke und Gruß, Heiko
Das ist keine modulspezifische Frage, sondern eine generelle Frage zu FHEM.
Und die wird in der Dokumentation auch ausführlich beantwortet => Doku lesen
pah
Vielen Dank für den freundlich dezenten ROTEN Hinweis.
Wenn ich diese Information in den Tiefen der Doku gefunden hätte, hätte ich hier nicht gefragt, soviel sei klar.
Weiterhin finde ich es in höchstem Maße ineffizient, wenn mehrere User mit der gleichen Fragestellung parallel aufwändig recherchieren, statt von jemandem, der das Problem bereits gelöst hat, einen kleinen Tipp zu bekommen. Ich dachte bisher, dazu seien Userforen da.
Aber egal. Zur Tatsache, dass dies nichts mit dem Modul zu tun hat: touché! Ich werde die Frage, falls ich weiterhin keine Lösung finde, in einem anderen Thread stellen.
Mein Dank für einen Anpfiff hält sich logischerweise in Grenzen - trotzdem Gruß, Heiko
Henning baust du das noch ein bitte
Zitat von: ulli am 17 Juli 2019, 21:16:40
Habe den pct100 fix selbst gemacht, kannst die ihn einplegen?
Man ersetzt im Set befehl folgende Zeile
$cmd = "?go=to_pos&roller_pos=" . $targetpct;
Durch diese
$cmd = "?go=to_pos&roller_pos=" . ($pctnormal ? $targetpct : 100 - $targetpct);
Danke im Voraus!
@ulli: Normalerweise mache ich gar nichts für Leute, die mich mit "Henning" anreden... :o
Ausnahmsweise, und weil Du Dir die Mühe gemacht hast: Ich habe das eingecheckt.
LG
pah
@u918244: Nicht meckern, Doku endlich lesen. Und bitte keine Fragen stellen, die schon eine gefühlte Million mal gestellt wurden. Dafür ist das Forum nämlich NICHT da.
Zitat von: Prof. Dr. Peter Henning am 30 Juli 2019, 21:21:25
@u918244: Nicht meckern, Doku endlich lesen.
Ich bin dabei, konnte bislang nur noch nichts Passendes finden.
Zitat von: Prof. Dr. Peter Henning am 30 Juli 2019, 21:21:25
Und bitte keine Fragen stellen, die schon eine gefühlte Million mal gestellt wurden.
Das ist ja gut, dann gebe ich jetzt mal
"readingsProxy mehr als ein Reading einbinden" in die Forums-Suche ein. Müsste ja mehr als 1 Million Fundstellen geben...
...
Mist, nur eine, nämlich meine eigene Frage.
Scheint ja doch noch nicht so oft gefragt worden zu sein...
Sonst schick mir doch bitte mal jemand die 999.999 Stellen, die hier helfen. Durch die lese ich mich dann auch noch durch. Geht bestimmt schneller, als von jemandem, der sich auskennt, eine kurze Antwort zu bekommen.
Danke und Gruß, Heiko
Hallo Heiko,
Das gehört hier wirklich nicht mehr in den Beitrag. Mach ein neues Thema im Anfängerbereich dazu auf.
Und sieh Dir vorher mal das an: https://wiki.fhem.de/wiki/ReadingsGroup (https://wiki.fhem.de/wiki/ReadingsGroup) Vielleicht erübrigt sich da ja eine weitere Anfrage. Etwas basteln musst Du schon selbst.
@u918244: Wer nicht einmal bereit ist, etwas Zeit auf die Suche nach seinen Antworten zu verwenden, ist hier eindeutig fehl am Platze. Die Leute, die "sich auskennen" sind nämlich auch nicht mit dem Wissen geboren worden, sondern haben es sich erarbeitet.
So long, und bitte meine Module nicht verwenden.
pah
Zitat von: Prof. Dr. Peter Henning am 30 Juli 2019, 21:21:25
@ulli: Normalerweise mache ich gar nichts für Leute, die mich mit "Henning" anreden... :o
UPS sorry, ging automatisch weil ich einen Henning kenne, war es ein Vorname für mich ;)
Danke
Zitat von: u918244 am 30 Juli 2019, 11:19:24
Kann ich beim Anlegen des readingsProxy mehr als ein Reading einbinden
commandref sagt
Makes (a subset of) a reading from one device available as a new device.
Also nein.
Gesendet von iPad mit Tapatalk Pro
Hi zusammen,
soweit ich den Code des Moduls glaube zu verstehen, holt sich das Modul die Info, ob ein Firmware-Update vorliegt aus dem Shelly selbst. Ich habe meine Shellys in der Fritzbox gesperrt, sprich sie bekommen kein Internet, also auch automatisch keine Updates.
Es gibt ja die Seite https://api.shelly.cloud/files/firmware über die ich manuell Abrufe, ob es ein Update gibt und falls dem so ist mache ich per eigenem Webserver ein OTA per URL auf dem Shelly.
Ja umständlich, aber so funkt einfach nichts nach aussen. Gäbe es die Möglichkeit das irgendwie ins Modul einzubauen, dass es quasi die Möglichkeit gibt ein (halb-)automatisches Offline-Update zu fahren?
Ich kann das leider nicht :(
Super Modul btw.
VG
Gesendet von meinem GM1913 mit Tapatalk
ZitatGäbe es die Möglichkeit das irgendwie ins Modul einzubauen
Nein, viel zu umständlich.
LG
pah
Ok, ich habs mir mal selber in bash gebaut, ist bestimmt nicht perfekt. Für mich und bei mir klappt es aber hervorragend, so kann auch ein Update direkt an alle devices verteilt werden.
Wer es testen möchte, das wäre dann hier zu finden: https://github.com/florie1706/ShellyUpdater
Moin,
zuerst einmal DANKE für das Modul. Ich habe einige Module im Einsatz und im Gegensatz zu meinen Sonoff Teilen bisher keine Probleme gehabt.
Da ich seit ein paar Tagen das Shelly EM im Einsatz habe, meine Frage: gibt es dafür auch eine Unterstützung in diesem Modul hier?
Gruß
Holger
Hallo zusammen,
leider schaffe ich es nicht, ein paar komplexere Befehle mit dem Shelly RGBW2 abzusetzen.
Pahs Rat mich an den REST-API Befehlen zu orientieren habe ich für mich auch nicht so ganz nachvollziehen können, die Seite
https://shelly-api-docs.shelly.cloud/#rgbw2 (https://shelly-api-docs.shelly.cloud/#rgbw2)
bringt mich da leider auch nicht weiter.
Nach viel Herumprobieren herausgefunden, dass das Zauberwort "config" wohl eine Rolle spielt, zumindest funktioniert der Befehl
set <RGBW2-device> config effect 4
Könnte mir mal jemand ein oder zwei Befehlsbeispiele posten, die z.B. Farbe und Helligkeit beinhalten?
LG,
al
Leute, das ist doch nun wirklich einfach. Mit dem Aufruf
http://<ip-adresse>/settings/color/0?effect=4
wird per REST der Effekt 4 eingeschaltet. Das steht schwarz auf weiß in der API-Referenz https://shelly-api-docs.shelly.cloud/#rgbw2-settings-color-0
Und im Modul wird so etwas aufgerufen als
set <device> config effect 4 0
(der letzte Wert ist der Kanalname - der muss laut API-Referenz (siehe oben: color/0) angegeben werden.
Diese Beschreibung steht aber auch in der CommandRef, man muss sie nur richtig lesen. (Edit: Auf Grund eines fehlenden "-Zeichens war das leider nicht in der CommandRef, sondern nur im Modul zu finden. Ist behoben.)
LG
pah
Zitat von: Prof. Dr. Peter Henning am 10 August 2019, 18:09:24
Leute, das ist doch nun wirklich einfach.
Finde ich nicht, sonst hätte ich nicht gefragt.
Zitat von: Prof. Dr. Peter Henning am 10 August 2019, 18:09:24Mit dem Aufruf
http://<ip-adresse>/settings/color/0?effect=4
Funktioniert bei mir nicht. Nach diesem http-Aufruf kommt bei mir eine leere Seite mit folgendem Text:
{"ison":false,"red":250,"green":249,"blue":255,"white":2,"gain":5,"effect":4,"default_state":"last","auto_on":0.00,"auto_off":0.00,"schedule":true,"btn_type":"momentary","btn_reverse":0,"schedule_rules":["0000ass-0123456-5%","0020bsr-0123456-off"]}Zitat von: Prof. Dr. Peter Henning am 10 August 2019, 18:09:24
Das steht schwarz auf weiß in der API-Referenz https://shelly-api-docs.shelly.cloud/#rgbw2-settings-color-0
hm...
Zitat von: Prof. Dr. Peter Henning am 10 August 2019, 18:09:24
Und im Modul wird so etwas aufgerufen als
set <device> config effect=4 0
Funktioniert bei mir ebenfalls nicht; - wohl aber funktioniert
set <RGBW2-device> config effect 4 - wie ich bereits schrieb.
Zitat von: Prof. Dr. Peter Henning am 10 August 2019, 18:09:24
Diese Beschreibung steht aber auch in der CommandRef, man muss sie nur richtig lesen.
dazu müsste ich die Passage in der CommandRef erst einmal finden, aber wahrscheinlich kann ich nicht einmal richtig suchen. Sorry, aber ich finde hier keinen "set"-Befehl erklärt: https://fhem.de/commandref.html#Shelly (https://fhem.de/commandref.html#Shelly)
Deine Antwort bringt mich leider nicht weiter. Ich kann auch nicht verstehen, warum Du nicht einfach auf meine Frage antwortest, nämlich ein Beispiel für einen fhem-Befehl, -der eine Farbe und einen Helligkeitsgrad beinhaltet- zu nennen. Das wäre zielführender als irgendwelche Verweise die für mich nicht nachvollziehbar sind.
VG,
al
ZitatNach diesem http-Aufruf kommt bei mir eine leere Seite mit folgendem Text:
Code:
{"ison":false,"red":250,"green":249,"blue":255,"white":2,"gain":5,"effect":4,"default_state":"last","auto_on":0.00,"auto_off":0.00,"schedule":true,"btn_type":"momentary","btn_reverse":0,"schedule_rules":["0000ass-0123456-5%","0020bsr-0123456-off"]}
Das ist doch wohl keine "leere Seite" !
Sondern der JSON-Code des Devices, der eindeutig mitteilt - "effect":4,, dass der Effekt 4 gesetzt wurde. Also ist die Behauptung
ZitatFunktioniert bei mir nicht.
einfach Unsinn.
set <device> config effect 4 0ist richtig - Copy&Paste-Fehler von mir.
CommandRef - hmm. Der HTML-Code für die Erklärung der Set-Befehle ist im Modul enthalten, wird aber aus irgendeinem Grund nicht in die CommandRef übernommen. muss ich mir ansehen.
Edit: Fehler gefunden, es fehlte ein "-Zeichen im HTML-Code.
Zitatwarum Du nicht einfach auf meine Frage antwortest, nämlich ein Beispiel für einen fhem-Befehl, -der eine Farbe und einen Helligkeitsgrad beinhaltet- zu nennen
Weil ich keine Lust habe, Trivialfragen zu beantworten.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 11 August 2019, 16:39:07
Weil ich keine Lust habe, Trivialfragen zu beantworten.
Warum antwortest Du dann? Dir liegt scheinbar mehr daran andere zurechtzuweisen, oder wie hier eine Aussage einfach als "Unsinn" abzutun.
Mangels meiner Fachkompetenz werde ich die von Dir genannten Verweise erneut lesen und versuchen zu verstehen, vielen dank für die Hinweise.
Dir lege ich freundlichst das Studium eines Wikipedia-Artikels nahe:
https://de.wikipedia.org/wiki/Netiquette (https://de.wikipedia.org/wiki/Netiquette)
VG,
al
Hallo
heute wurde ein Update auf die Shellys 2.5 gefahren.
Version: v1.5.1
Bei den Shellys muss danach die Kalibrierung neu gestartet werden, bzw. es fehlen nach dem Update die Status Rückmeldung "open,closed".
Dadurch kamen einige "DIOF" Abfragen durcheinander!
jetzt habe ich nur bei einem statt "open" den Wert 112 im Status bzw. in der Position?
Zitat von: Pfriemler am 31 März 2019, 17:48:39
a) Zum Thema "Status bei manuellem Schalten":
Ich habe gerade frisch einen Shelly1 mit Firmware 1.4.8. und mit Modulversion 1.81 im Test. Da ist nichts mit automatischer Meldung nach manuellem Schalten, nur nach Pollen. Habe ich was übersehen? Galt die aktive Meldung wirklich nur für die beta vom Shelly2?
b) ich bekomme frisch nach dem Einrichten mit schöner Regelmäßigkeit jede Minute Fehler ins Log:
2019.03.31 17:34:53.990 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4693.
2019.03.31 17:34:53.990 1: stacktrace:
2019.03.31 17:34:53.991 1: main::__ANON__ called by fhem.pl (4693)
2019.03.31 17:34:53.991 1: main::readingsBulkUpdateIfChanged called by ./FHEM/36_Shelly.pm (650)
2019.03.31 17:34:53.991 1: main::Shelly_status called by ./FHEM/36_Shelly.pm (604)
2019.03.31 17:34:53.991 1: main::__ANON__ called by FHEM/HttpUtils.pm (606)
2019.03.31 17:34:53.991 1: main::__ANON__ called by fhem.pl (739)
Geht auch nach Neustart nicht weg.
c) nur am Rande: wegen a) MQTT zu nutzen wäre für mich keine Hürde, weder mit Shelly-Fw noch mit Tasmota, habe letztere reichlich im Einsatz. Allerdings habe ich gerade festgestellt, dass ein Shelly 1 (erste Version) mit Tasmota 0,3W weniger verbraucht, also 0,4 im Standby und 0,7 Watt mit aktivem Relais. Weniger Watt = weniger warm = weniger Veschleiß, gerade bei beengtem Einbau.
... Ruder zurück, nach letzten Messungen nehmen sich beide doch nicht so viel. Keine Ahnung, heute nachmittag war der Unterschied deutlich sichtbar, ich wechselte zwischen beiden Aktoren.
Tasmota bringt übrigens vom Fleck weg das Eingangs-Schalterverhalten "edge" mit, d.h. jede Schaltzustandsänderung bedeutet auch eine Relais-Änderung.
Wie wurde diese Fehlermeldung behoben ?
Habe im Moment eine ähnliche Fehlermeldung :
2019.08.26 17:30:27 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4752.
2019.08.26 17:30:27 1: stacktrace:
2019.08.26 17:30:27 1: main::__ANON__ called by fhem.pl (4752)
2019.08.26 17:30:27 1: main::readingsBulkUpdateIfChanged called by ./FHEM/36_Shelly.pm (894)
2019.08.26 17:30:27 1: main::Shelly_status called by ./FHEM/36_Shelly.pm (848)
2019.08.26 17:30:27 1: main::__ANON__ called by FHEM/HttpUtils.pm (610)
2019.08.26 17:30:27 1: main::__ANON__ called by fhem.pl (745)
ZitatWie wurde diese Fehlermeldung behoben ?
Durch Verwendung der aktuellen Modulversion.
LG
pah
Danke für die Antwort,
Meine ist aktuell
36_Shelly.pm 19984 2019-08-11 15:16:11Z phenning
Vielleicht noch einen Tip ?
Aber ja:
1. Ignorieren, das ist nämlich nur eine Warnung ohne Konsequenzen.
2. Aussagekräftige Beschreibungen liefern, mit denen man etwas anfangen kann.
LG
pah
Hallo,
ich versuche gerade die Schaltspiele und die Einschaltzeit der LED Leuchtmittel aufzuzeichnen. Dazu habe ich mit ein Notify erstellt das bei allen Aktoren mit Licht im Namen reagiert.
Licht.*:(on|off|set_on|set_off) {
Log(3, "NF_Schaltungen: ". $NAME ."|".$EVENT);
}
Nun habe ich aber festgestellt, dass bei den Shelly Aktoren immer drei Events ausgelöst werden. LichtHWR ist ein Shelly1 gesteuert durch das Shelly Modul. LichtBude und LichtDiele2 sind normale HM Aktoren. LichtTV ist ein mit Tasmota geflashter Sonoff via MQTT.
2019.08.31 12:41:23 3: NF_Schaltungen: LichtHWR|on
2019.08.31 12:41:23 3: NF_Schaltungen: LichtHWR|on
2019.08.31 12:41:23 3: NF_Schaltungen: LichtHWR|on
2019.08.31 12:41:52 3: NF_Schaltungen: LichtHWR|off
2019.08.31 12:41:52 3: NF_Schaltungen: LichtHWR|off
2019.08.31 12:41:52 3: NF_Schaltungen: LichtHWR|off
2019.08.31 12:46:19 3: NF_Schaltungen: LichtHWR|on
2019.08.31 12:46:19 3: NF_Schaltungen: LichtHWR|on
2019.08.31 12:46:19 3: NF_Schaltungen: LichtHWR|on
2019.08.31 12:49:10 3: NF_Schaltungen: LichtBude|on
2019.08.31 12:49:23 3: NF_Schaltungen: LichtBude|off
2019.08.31 12:49:25 3: NF_Schaltungen: LichtDiele2|on
2019.08.31 12:49:40 3: NF_Schaltungen: LichtDiele2|off
...
2019.08.31 13:28:30 3: NF_Schaltungen: LichtTV|set_on
Mit ist nicht ganz klar, warum beim Shelly drei Events ausgelöst werden und wie ich das verhindern kann. Mit
attr event-min-interval .*:3 hat es nicht funktioniert.
Könnte mich bitte mal jemand Erleuchten.
Betreibe 2 Stück Shelly 2.5 im Modus roller. Klappte bisher sehr gut. Nach dem letzten Shelly-Update ist sogar die Position präzise, so dass ASC auch Entschatten kann. Bei einer falschen Positionsrückmeldung ist ASC von einem Handeingriff ausgegangen und hat nicht mehr Entschattet.
Jetzt ist ein anderes Problem aufgetreten. Nach fhem Neustart kommt keine Verbindung zwischen dem Modul und Shelly zustande.
network steht auf not connected
state steht auf Error
Egal welche get Befehle aufgerufen werden oder auch Set password neu - keine Wirkung.
Der Fehler kommt sowohl mit/ohne feste IP. Die FritzBox vergibt ohnehin wieder die selbe IP, egal ob gelöscht oder nicht.
Nur mit praktisch einer Neueinrichtung der Module kommt es wieder zur Verbindung.
Was könnte die Ursache sein?
Danke.
Hallo zusammen,
habe das Problem, dass der hsv-Befehl aus der commandref bei meinem ShellyRGB2 nicht funktioniert:
set <name> hsv <hue value 0..360><saturation value 0..1><brightness value 0..1> 6-digit hex string to set the color.
Abgesehen davon sollte es doch bei saturation und brightness eher "0..100" und nicht "0..1" heißen, oder?
Muss da außerdem kein Leerzeichen zwischen die Zahlenwerte?
Davon abgesehen haut es einfach nicht hin.
Ein set shellyRGB hsv 120 30 10 FF0000 wird von der Leuchte ignoriert.
Im log steht dann:
Color::hsv2rgb value our of range [120,,]. should be in 0..1.
und
set shellyRGB hsv 1 30 10 FF0000
geht auch nicht :-(
Egal was ich auch ausprobiere, meine Leuchte bleibt dunkel.
Kann jemand da "Licht ins Dunkel" bringen?
VG,
al
Hallo,
erst einmal Danke für dieses Modul - mit einem ersten Shelly1 v3 funktionierte es auf Anhib und out-off-the-box ;)
Jetzt hat sich bei mir noch eine Frage aufgedrängt: werden evtl. einmal die set extensions eingebaut?
Gruß, Christoph
@justcallmeal:
Das ist nur ein Fehler in der CommandRef. Selbsverständlich funktioniert die Eingabe von
set <device> hsv <hue value 0..360>,<saturation value 0..1>,<brightness value 0..1>.Also z.B.
set <device> hsv 120,1,0.3ZitatAbgesehen davon sollte es doch bei saturation und brightness eher "0..100" und nicht "0..1" heißen, oder?
Nein, siehe oben.
ZitatMuss da außerdem kein Leerzeichen zwischen die Zahlenwerte?
Nein, siehe oben.
ZitatEgal was ich auch ausprobiere, meine Leuchte bleibt dunkel.
Soll sie auch. Alle Set-Befehle zum Setzen der Farbe schalten diese nicht an. Der Befehl
Zitatset <device> on
muss zusätzlich kommen.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 22 September 2019, 06:45:36
Das ist nur ein Fehler in der CommandRef.
ahhhh... jetzt kommt Licht ins Dunkel :) Danke für Deine Erklärungen!
Korrigierst Du die Commandref noch entsprechend, bitte?
VG,
al
Hallo zusammen, ich kann momentan leider meinen Shelly2.5 nicht per FHEM nutzen. Ich erhalt immer als Meldung:
"Error: roller blind still moving, wait for some time"
Internals:
DEF 192.168.178.44
DURATION 0
FUUID 5d851ed9-f33f-2e6c-b208-6f5188e24eaa5333
FVERSION 36_Shelly.pm:v2.6.0-s19984/2019-08-11
INTERVAL 60
NAME BUT_Rollladen
NR 184
STATE pct
TCPIP 192.168.178.44
TYPE Shelly
READINGS:
2019-09-22 15:23:00 network not connected
2019-09-22 15:23:00 state Error
2019-09-22 15:23:00 updateneeded false
Attributes:
DbLogExclude .*
alexaName Rollladen Thomas
alexaRoom Büro Thomas
alias Rollladen Thomas
cmdIcon open:fts_shutter_up close:fts_shutter_down stop:fts_shutter_manual half:fts_shutter_50
devStateIcon opening:fts_shutter_up@red closing:fts_shutter_down@red true:10px-kreis-gruen false:10px-kreis-rot 100:fts_shutter_100 0:fts_shutter_10 9\d:fts_shutter_90 8\d:fts_shutter_80 7\d:fts_shutter_70 6\d:fts_shutter_60 5\d:fts_shutter_50 4\d:fts_shutter_40 3\d:fts_shutter_30 2\d:fts_shutter_20 1\d:fts_shutter_10 0\d.*:fts_shutter_10 set_.*:fts_shutter_updown
genericDeviceType blind
group Rollladen
icon fts_shutter_30
mode roller
model shelly2.5
pct100 closed
room Büro Thomas
shellyuser thomas
stateFormat pct
userReadings updateneeded {if(ReadingsVal($NAME,"firmware","") =~ ("needed") ){'true'} else {'false'}}
verbose 0
webCmd open:close:half:stop:pct
Jemand einen Tipp für mich?
Gruß Thomas
Zitat von: Humpelpumpel am 22 September 2019, 15:26:31
Hallo zusammen, ich kann momentan leider meinen Shelly2.5 nicht per FHEM nutzen. Ich erhalt immer als Meldung:
"Error: roller blind still moving, wait for some time"
Zitat von: Prof. Dr. Peter Henning am 01 Februar 2019, 16:40:57
Ist mit der gerade eingecheckten Version 1.81 behoben
LG
pah
...Update gemacht?
Jo, ist aktuell. :)
Edit: Tut wieder, sehr seltsam...
Nö, nicht seltsam. Anfänger machen solche Fehler ...
LG
pah
Guten Tag zusammen,
so langsam verzweifel ich am Shelly 2.5.
Erstmal von vorne. Ich habe vor 3 Wochen an einem Freitag Abend meinen Shelly in Betrieb genommen. Den Samstag in der nachfolgenden Woche, ist er im Netzwerk nicht mehr erreichbar gewesen. Ein Neustart der Fritz!Box 6590 hat ausgereicht, dass er wieder ansprechbar war. Auf den Tag genau 1 Woche später wieder das gleiche Spiel. Diesmal hat aber kein Neustart gereicht. Ich musste einen Strom Reset machen. Jetzt ging das die ganze Woche gut und was passiert heute morgen ? Der Shelly ist wieder nicht erreichbar, obwohl ich um 08:00 Uhr noch auf der Weboberfläche war, ist er seit 09:45 Uhr ausgestiegen.
Gibt es einen Befehl für den Shelly 2.5 um Ihn zu Rebooten ? Ich würde mir dann ein at schreiben, was den Shelly jede Nacht Neustarten läßt.
Gruß
Sven
Zitat von: xitolein am 28 September 2019, 13:26:46
im Netzwerk nicht mehr erreichbar
Daraus lese ich, dass auch ein ping auf die IP ins Leere liefe. Ich fürchte, in dem Fall erginge es dem at genauso.
Solange die Ursache unklar ist (Shelly oder Fritte usw.), könnte die Lösung schwrierig werden.
Ich habe eine recht alte Fritte und hatte mal ähnliche Probleme mit einem esp8266 wg. schwachem Empfang. Verabschiedete sich dann und wann.
In der FB gabs die Option "Sendeleistung automatisch auf den tatsächlichen Bedarf verringern", welche ich deaktivierte - dann war alles gut.
Wird Dein Problem nicht lösen, aber ggf. ein Hinweis auf mögliche Fehlereingrenzung :D
Viele Grüße
rob
Hallo,
mein heutiges Problem konnte ich nur mit einem FritzBox Neustart lösen. Zwei vorherige Strom Reset führten nicht zum Erfolg. Die FritzBox und der Shelly sind Luftlinie 5 m auseinander ohne Störende Hindernisse dazwischen.
Habe heute Versucht dem Shelly eine Statische IP zu vergeben und bekam die auf dem Bild ersichtliche Fehlermeldung.
Aufgrund dessen gehen ich mal davon aus, dass der Fehler in der Fritzbox liegen muss.
Gruß
Sven
Hi.
So eine Meldung hatt ich noch nicht von der FB. Kann ich leider auch nur raten :(
Würde Dir das hier ggf. helfen? https://en.avm.de/service/fritzbox/fritzbox-3272/knowledge-base/publication/show/201_Configuring-FRITZ-Box-to-always-assign-the-same-IP-address-to-a-network-device/ (https://en.avm.de/service/fritzbox/fritzbox-3272/knowledge-base/publication/show/201_Configuring-FRITZ-Box-to-always-assign-the-same-IP-address-to-a-network-device/)
Viele Grüße
rob
Ich tippe eher auf einen Fehler beim Bediener - die IP-Adresse des DNS-Servers hat nämlich nur drei statt vier Zahlen...
LG
pah
Zitat von: xitolein am 28 September 2019, 21:45:41
...
Aufgrund dessen gehen ich mal davon aus, dass der Fehler in der Fritzbox liegen muss.
...
Zitat von: Prof. Dr. Peter Henning am 29 September 2019, 18:02:33
Ich tippe eher auf einen Fehler beim Bediener - die IP-Adresse des DNS-Servers hat nämlich nur drei statt vier Zahlen...
Ich gehe davon aus, dass es mittlerweile funktioniert, dennoch möchte ich zu diesem Thema noch ergänzen,
dass diese Meldung auch bei dem Versuch einen Wifi Client Backup zu definieren, der die gleiche DNS, wie der originale Wifi Client hat (sowohl per http command, als auch mit der http App) kommt.
Es könnte also durchaus sein, dass weder die FritzBox noch der User die Ursache war.
lg
Gernot
Kann jemand sagen, ob die Shelly 1 PM unterstützt werden? Also ein Auslesen der Leistung / des Stroms möglich ist?
Guten Morgen zusammen,
ich habe mir einen Shelly Plug S zum Probieren geholt.
Hauptsächlich geht es mir um die Leistungsmessung. Testweise habe ich mal einen Kühlschrank reingesteckt.
Das funktioniert soweit auch, nur ist mir beim Erstellen des SVG-Plots ein Sägezahn als Verlauf aufgefallen, den ich mir so erst einmal nicht erklären konnte. Erwartet hatte ich ein Rechteck.
Ein Blick in die entsprechende Log-Datei lässt die Ursache für diese Darstellung aber leicht erkennen.
Solange eine Leistung gemessen wird, werden die Daten auch schön im vorgegebenen Intervall aufgezeichnet. Zum Testen habe ich das Attribut interval gesetzt:
Attributes:
interval 30
model shellyplug
Hier der Auszug aus der Log-Datei:
2019-10-13_05:52:03 Shelly1 power: 50.39
2019-10-13_05:52:33 Shelly1 power: 51.01
2019-10-13_05:53:03 Shelly1 power: 51.48
2019-10-13_05:53:33 Shelly1 power: 51.88
2019-10-13_05:54:03 Shelly1 power: 52.35
2019-10-13_05:54:33 Shelly1 power: 52.41
2019-10-13_05:55:03 Shelly1 power: 52.59
2019-10-13_05:55:33 Shelly1 power: 52.53
2019-10-13_05:56:03 Shelly1 power: 52.65
2019-10-13_05:56:33 Shelly1 power: 52.55
2019-10-13_05:57:03 Shelly1 power: 52.45
2019-10-13_05:57:34 Shelly1 power: 52.71
2019-10-13_05:58:04 Shelly1 power: 52.49
2019-10-13_05:58:34 Shelly1 power: 52.04
2019-10-13_05:59:04 Shelly1 power: 0
2019-10-13_07:02:15 Shelly1 power: 48.03
2019-10-13_07:02:46 Shelly1 power: 45.43
2019-10-13_07:03:16 Shelly1 power: 46.54
2019-10-13_07:03:46 Shelly1 power: 47.16
2019-10-13_07:04:16 Shelly1 power: 47.94
2019-10-13_07:04:46 Shelly1 power: 48.72
Bis zum Messwert power: 0 wird alle 30 Sekunden geloggt.
Dann werden von 05:59:04 bis 07:02:15 bis zu einem neuen Messwert keine Zwischenwerte aufgezeichnet.
Ab dann werden wieder bis zum nächsten power: 0 die Werte aufgezeichnet.
Liefert der Shelly trotz polling alle 30 Sekunden dann keinen Wert?
Oder wird dies vom Modul so ausgewertet?
Hier noch ein List vom Shelly:
Internals:
CFGFN
CHANGED
DEF 192.168.2.230
DURATION 0
FUUID 5da089c4-f33f-8873-9ac4-f92f3345cf0b8ea1
FVERSION 36_Shelly.pm:v2.7.0-s20282/2019-09-30
INTERVAL 30
NAME Shelly1
NR 45339
STATE on
TCPIP 192.168.2.230
TYPE Shelly
READINGS:
2019-10-11 15:55:16 cloud disabled
2019-10-13 07:13:17 energy 254.9
2019-10-11 15:58:17 firmware v1.5.2
2019-10-11 15:55:16 network <html>connected to <a href="http://192.168.2.230">192.168.2.230</a></html>
2019-10-13 07:12:47 power 0
2019-10-11 15:55:16 relay on
2019-10-11 15:55:16 state on
Attributes:
interval 30
model shellyplug
Schönen Sonntag noch
Norbert
Das ist derzeit im Modul so programmiert, dass nur bei Änderung des Wertes ein Event generiert wird. Einfach einen anderen Plot-Modus verwenden.
LG
pah
Hallo pah,
Danke für den Tipp.
Ich habe jetzt im SVG den plot-type von lines auf steps geändert.
Und schon ist das Ergebnis wie gewünscht.
Norbert
Hallo,
ich habe im Log folgenden Fehler
2019.10.22 13:16:17 1: PERL WARNING: Use of uninitialized value $hastimer in string ne at ./FHEM/36_Shelly.pm line 1111.
2019.10.22 13:16:17 1: stacktrace:
2019.10.22 13:16:17 1: main::__ANON__ called by ./FHEM/36_Shelly.pm (1111)
2019.10.22 13:16:17 1: main::Shelly_dim called by ./FHEM/36_Shelly.pm (1075)
2019.10.22 13:16:17 1: main::__ANON__ called by FHEM/HttpUtils.pm (634)
2019.10.22 13:16:17 1: main::__ANON__ called by fhem.pl (747)
Kann mir jemand sagen warum der fehler aufkommt?
Das ist nur eine Warnung, kein wirklicher Fehler. Kann ignoriert werden und wird in irgendeinem der nächsten Releases abgefangen.
LG
pah
Alles klar, vielen dank für die Info.
Hallo Zusammen,
ich hab seit knapp einem 3/4 Jahr die Shellys in FHEM eingebunden über das Modul. Seit nun gut 4 Wochen ist einer von 4 Shelly1 nicht mehr per FHEM zu erreichen.
Die Verbindung liefert im Log ein Time Out. Erstaunlicherweise ist er aber über die App, als auch über die Web-Addresse zu erreichen. Ich vermute eigentlich einen defekt des Device, da es nur 1 von 4 betrifft und ich vor dem Ausfalls keine Änderungen am Netz oder Hardware vorgenommen habe.
Bin über jeden Ansatz dankbar denn den Defekt zu erklären obwohl App/Web funktionieren wird auch spannend.
Netzwerk: FB7390, Shellys1 mit static IP angebunden.
List des Device:
Internals:
CFGFN
DEF 192.168.1.199
DURATION 0
FUUID 5db56fe5-f33f-5175-25d9-7ca80abcb8fab8d7
INTERVAL 60
NAME myShelly
NR 66
STATE Error
TCPIP 192.168.1.199
TYPE Shelly
READINGS:
2019-10-27 11:26:48 cloud disabled
2019-10-27 11:26:48 firmware v1.5.2
2019-10-27 11:28:36 network not connected
2019-10-27 11:26:48 relay on
2019-10-27 11:28:42 state Error
Attributes:
model shelly1
Gruß Martin
Das lässt sich ganz einfach überprüfen.
Mit dem Aufruf http://<ip-Adresse>/status beispielsweise sollte man den Status angezeigt bekommen, alle weiteren Abfragen und Befehle sind hier dokumentiert: http://shelly-api-docs.shelly.cloud/#shelly-family-overview
Wenn diese funktionieren, aber das Device aus FHEM heraus nicht mehr erreichbar ist: Fehler in der Konfiguration des FHEM-Devices.
LG
pah
Hallo PAH,
ich hab es noch nicht im Thread gefunden, wird der Shelly Dimmer auch schon vom Modul unterstützt ? Der scheint noch recht neu zu sein.
Grüße
Christian
Hallo pah,
Danke für den Hinweis. Die API bzw. Status hatte ich nicht auf dem Schirm. Kurioserweise ein List von gerade zeigt jetzt wieder connected.
- Ich hab bis dato, IP-Adresse gewechselt um Adress-Konflikte auszuschließen
- Neue "saubere" FEHM Installation verwendet
- Netzwerk Hardware / Shelly reset durchgeführt
Mir fehlt wirklich ein Ansatz wo ich noch ansetzen kann.
NB: Ping von den beiden Raspbian Installation hat einen Paket loss größer 90%, erklärt warum manchmal ein connect zustande kommt. Die Ursache ist mir nur nicht klar, denn es taucht nur bei dem einen Shelly auf und nur bei PING von den Raspbians.
Internals:
CFGFN
DEF 192.168.1.199
DURATION 0
FUUID 5db56fe5-f33f-5175-25d9-7ca80abcb8fab8d7
INTERVAL 60
NAME myShelly
NR 66
STATE off
TCPIP 192.168.1.199
TYPE Shelly
READINGS:
2019-10-27 11:26:48 cloud disabled
2019-10-27 11:26:48 firmware v1.5.2
2019-10-28 22:22:44 network <html>connected to <a href="http://192.168.1.199">192.168.1.199</a></html>
2019-10-27 11:42:05 relay off
2019-10-28 22:22:44 state off
Attributes:
model shelly1
Zitat von: Prof. Dr. Peter Henning am 27 Oktober 2019, 11:46:52
Das lässt sich ganz einfach überprüfen.
Mit dem Aufruf http://<ip-Adresse>/status beispielsweise sollte man den Status angezeigt bekommen, alle weiteren Abfragen und Befehle sind hier dokumentiert: http://shelly-api-docs.shelly.cloud/#shelly-family-overview
Wenn diese funktionieren, aber das Device aus FHEM heraus nicht mehr erreichbar ist: Fehler in der Konfiguration des FHEM-Devices.
LG
pah
...hast du den schon mal Stromfrei (ggf. Haus-Sicherung raus) gemacht ? Ich habe gelegentlich bei meinen Sonoffs (auch mit ESP8266) das auch, dass die nicht mehr erreichbar sind, nach Stromlos und neu verbunden dann alles wieder top...
Hallo,
besteht die Möglichkeit das "setList" Attribut mit einzubauen? Mein Shelly Plug S hängt vor dem Gefrierschrank und soll nicht versehentlich über FHEM ausgeschaltet werden - ein setList "on" könnte die Lösung sein, vielleicht hat jemand aber noch eine andere Idee.
Weiterhin würde ich gerne anregen "mode" wenn es als Attribut beim Shelly 2.5 nicht gesetzt wurde mit einem Default Wert (z. B. "relay") intern vorzubelegen.
An dieser Stelle auch einen herzlichen Dank für das Modul und die Pflege!
setList ist dafür nicht geeignet - das hat ganz eine ganz andere Semantik.
Ich überlege mir mal etwas.
LG
pah
wie wäre es mit attr <device> webcmd :
Dann wären zumindest die on/off Buttons weg.
Alternativ dazu einfach "webcmd on".
Zitat von: uxtuner am 02 November 2019, 08:40:05
Hallo,
besteht die Möglichkeit das "setList" Attribut mit einzubauen? Mein Shelly Plug S hängt vor dem Gefrierschrank und soll nicht versehentlich über FHEM ausgeschaltet werden - ein setList "on" könnte die Lösung sein, vielleicht hat jemand aber noch eine andere Idee.
Hey - ich nutze zwar nicht dieses Modul, sondern gehe über MQTT aber habe das gleiche Thema bei meiner Waschmaschine gehabt. Du müsstest zwar ein wenig umbauen aber am Ende wäre es das gleiche..
Anbei mal mein devStateIcon:
{ my $amp = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";; my $pic = ReadingsVal($name,"running","") eq "true"?'scene_laundry_room_fem@green':'scene_laundry_room_fem';; my $text = ReadingsVal($name,"running","") eq "true"?"Waschmaschine läuft - Aktuell: ".ReadingsVal($name,"power","")." W":'Standby';; my $show = "$amp" eq "gelb" ? "<a href=\"/fhem?cmd.dummy=set $name x_update&XHR=1\">".FW_makeImage("10px-kreis-".$amp)."</a>" : "<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage("10px-kreis-".$amp)."</a>";; "<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\"></a>".FW_makeImage($pic)." $text </div>" }Von der Logik her, geht das sicher besser aber ich habe so ein Icon, welches mir zeigt ob das Gerät an ist oder nicht und was es gerade verbraucht und so weiter. Aber ich habe den toggle Link (schalten über das Icon auf dem FHEM Web-IF) ins nichts geschickt. Also = Symbol nicht mehr klickbar.
Hinzu das bereits beschriebene webcmd :
Im Bild liegt die Maus auf dem Icon der Waschmaschine. Man sieht sie im Screenshot nicht aber man sieht das dort am Ende einfach nur ON steht und nichts klickbar ist. (Außer natürlich der kleine Kreis vor dem Icon)
Zitat von: cs-online am 28 Oktober 2019, 13:44:53
Hallo PAH,
ich hab es noch nicht im Thread gefunden, wird der Shelly Dimmer auch schon vom Modul unterstützt ? Der scheint noch recht neu zu sein.
Grüße
Christian
Da das bisherige Modul mit meinen Shelly1 einen top Job macht hoffe ich auch auf eine zukünftige Unterstützung des Shelly Dimmers.
Was ist denn der Unterschied zwischen den Readings power und energy im ShellyPlug? Die Webseite des Shelly selbst sagt, dass power eben Leistung ist (in Watt), aber im Wiki und in der commandref finde ich keine Erklärung für Energie. Hat jemand einen Tipp?
energy ist die über die Zeit integrierte power. Macht der Shelly selbst.
LG
pah
Zitathoffe ich auch auf eine zukünftige Unterstützung des Shelly Dimmers.
So wie das Modul aufgebaut ist, geht das sehr einfach. Ist einfach eine Variante des RGBW2, der ja als 4-fach Dimmer arbeiten kann.
Allerdings habe ich diese Hardware nicht, und werde sie auch nicht kaufen, weil ich dafür keine Verwendung habe.
LG
pah
Hallo PAH,
ich bin nun stolzer Besitzer eines Shelly Dimmers und habe in der Commandref mit Entzücken gesehen, dass du dort auch schon den Dimmer beschreibst. Ich habe den mit
defmod Dimmer_WZ Shelly 192.168.2.35
attr Dimmer_WZ defchannel 0
attr Dimmer_WZ mode white
attr Dimmer_WZ model shellyrgbw
attr Dimmer_WZ room Wohnzimmer
attr Dimmer_WZ verbose 5
eingebunden. Ich bekomme auch den PCT-Wert angezeigt, den ich in der Shelly-APP sehe, aber wenn ich schalten will, bekomme ich mit Verbose 5:
2019.11.22 15:14:23 5: [Shelly_status] Issue a non-blocking call to http://192.168.2.35/status
2019.11.22 15:14:23 5: [Shelly_status] has obtained data {"wifi_sta":{"connected":true,"ssid":"Schmitzes WLAN","ip":"192.168.2.35","rssi":-63},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":false},"time":"15:14","serial":1,"has_update":false,"mac":"CC50E3F3AA67","lights":[{"ison":false,"mode":"white","brightness":31}],"meters":[{"power":0.00, "is_valid":true, "timestamp":1574435663,"counters":[0.000, 0.000, 0.000],"total":0}],"inputs":[{"input":0},{"input":0}],"tmp":{"tC":45.28,"tF":113.50, "is_valid":"true"},"calib_progress":0,"overtemperature":false,"loaderror":false,"overload":false,"update":{"status":"idle","has_update":false,"new_version":"20191120-141347/v1.5.6-rc2@4776adad","old_version":"20191120-141347/v1.5.6-rc2@4776adad"},"ram_total":39600,"ram_free":29000,"fs_size":233681,"fs_free":141564,"uptime":1151}
2019.11.22 15:14:26 4: [Shelly_Set] switching default channel 0
2019.11.22 15:14:26 5: [Shelly_dim] Issue a non-blocking call to http://192.168.2.35/white/0?turn=on
2019.11.22 15:14:26 5: [Shelly_dim] has obtained data Not Found
2019.11.22 15:14:26 1: [Shelly_dim] has invalid JSON data
Kannst du da helfen oder habe ich vielleicht noch was falsch eingestellt ?
....und eine Frage hätte ich noch, kann man da vielleicht einen Slider hinzufügen ? Ich habe das mal bei einem Dummy über Setlist Slider gelöst, aber der Shelly hat das Attribut Setlist anscheinend nicht....
Grüße
Christian
...Nachtrag: Ich habe folgendes festgestellt: Im Log steht ja:
2019.11.22 18:08:04 5: [Shelly_dim] Issue a non-blocking call to http://192.168.2.35/white/0?turn=on
Wenn ich also im Browser folgendes eingebe:
http://192.168.2.35/white/0?turn=on
dann kommt als Ausgabe:
Not Found, aber wenn ich wie in der API aeingebe:
http://192.168.2.35/light/0?turn=on
eingebe, wird folgendes ausgegeben:
{"ison":true,"mode":"white","brightness":80}
Kannst du das im Modul anpassen ?
EDIT: Ich habe mal im Modul nach "white" gesucht und bei allen "white/0" nach "light/0" geändert und jetzt kann ich mit dem Modul schalten... Aber wenn ich den Code verstanden habe, sollte eigentlich auch ein Slider erscheinen und das kommt leider auch mit den Änderungen nicht....
...habs selber hinbekommen:
im Modul unter Abschnitt
my %setsrgbww = (
"pct" => "B",
ändern in
"pct:slider,1,1,100" => "B"
Dann kann darüber die Helligkeit gesteuert werden. Aber aufgepasst: Damit wird der Dimmer nicht automatisch bei 0 auf aus und bei 100 auf an geschaltet, das kann und muss man separat schalten.
@PAH: Kannst du das ggf. bei einem Update beides (s.Post drüber) mit einbringen ?
Grüße
Christian
Mal langsam.
Der Shelly Dimmer wird bisher im Modul nicht unterstützt. Die API-Calls mit "white" sind für den Shelly RGBW2 im White-Modus.
Ich habe oben geschrieben, dass das nur eine einfache Änderung wäre, den Dimmer zu unterstützen. Aber erstens habe ich den Dimmer selber nicht, und zweitens ist nicht akzeptabel, durch eine brutale Ersetzung im Modul die Anbindung des Shelly RGBW2 zu zerstören. Das muss mit etwas mehr Überlegung geschehen, und dafür habe ich frühestens in der übernächsten Woche Zeit.
Betreffend den Slider: Das wird nicht ins Modul eingebaut. FHEM bietet mit den Attributen widgetOverride und webCmd genügend Möglichkeiten, die GUI-Elemente beliebig anzupassen.
LG
pah
Hallo pah,
alles gut, sollte ja überhaupt keine Kritik sein, wollte nur meine Erkenntnisse teilen, weil der Dimmer ja noch recht neu ist und du ja auch schriebst, dass du selber keinen hast. Mit den kleinen Veränderungen läuft das bei mir bis jetzt im Testbetrieb sehr gut.
Wenn ich dich irgendwie unterstützen kann, z.B. etwas zu testen, würde ich das gerne tun. ich glaube alle hier sind dir für deine Arbeit sehr dankbar und wir können sicherlich noch etwas warten, viele würden das ohne dein Modul gar nicht ans Laufen bekommen. Daher keine Eile :-)
Schöne Grüße und ein schönes Wochenende,
Christian
So, habe mir gerade 30 Minuten Zeit genommen, da ein Kollege mir einen Shelly Dimmer geliehen hat.
Neue Version des Moduls mit explizitem Support für model=shellydimmer wurde soeben eingecheckt.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 27 November 2019, 16:34:31
So, habe mir gerade 30 Minuten Zeit genommen, da ein Kollege mir einen Shelly Dimmer geliehen hat.
Neue Version des Moduls mit explizitem Support für model=shellydimmer wurde soeben eingecheckt.
LG
pah
Vielen Dank ;)
Gesendet von meinem GM1913 mit Tapatalk
Ich sehe gerade, dass Allterco da noch mehr Optionen eingebaut hat, um mit den Buttons (2 Eingänge) separate Schaltvorgänge auszulösen.
Habe das gerade noch nachgebessert, die aktuelle Version ist also 2.11.
Ich habe zwar keinen Taster zum Testen zur Hand, aber wenn man das betreffende Kommando beim Shelly in die Oberfläche einträgt:
http://<ip-adresse>/fhem?XHR=1&cmd=set%20dimmer%20button_on%200
(0 oder 1 an der letzten Stelle), registriert das Modul das korrekt.
LG
pah
Hallo pah,
danke, ich werde das am Wochenende gerne mal testen :-)
Grüße
Christian
Zitat von: Prof. Dr. Peter Henning am 27 November 2019, 16:53:23
Ich sehe gerade, dass Allterco da noch mehr Optionen eingebaut hat, um mit den Buttons (2 Eingänge) separate Schaltvorgänge auszulösen.
Habe das gerade noch nachgebessert, die aktuelle Version ist also 2.11.
Ich habe zwar keinen Taster zum Testen zur Hand, aber wenn man das betreffende Kommando beim Shelly in die Oberfläche einträgt:
http://<ip-adresse>/fhem?XHR=1&cmd=set%20dimmer%20button_on%200
(0 oder 1 an der letzten Stelle), registriert das Modul das korrekt.
LG
pah
Hallo pah,
seit es die Firmware 1.5.6 gibt sind Actions für longpress vorgesehen, wirst du die auch kurzfristig mit deinem Modul unterstützen (button_long) ?
LG
Benötigt man nicht. Man kann einfach in die URL für ein button_long eine andere Button-Nummer eintragen, sagen wir 2 und 3, wenn die short actions 0 und 1 sind.
LG
pah
Hallo pah,
ich kann in der Commandref keine Button-Nummer finden, meinst du Channel oder habe ich etwas übersehen ?
Die Button-Nummerierung ist unabhängig von den Channels - nur bei Switching Devices kann man das 1:1 übersetzen. Wie man unter anderem daran ersieht, dass der Dimmer nur einen "Dimmkanal" (channel) hat, aber 2 Button-Inputs.
Es ist auch nicht nötig, in der Web-Oberfläche des Shelly als URL für die Button-Meldung das Shelly-FHEM-Device einzutragen und dann noch in FHEM mit einem notify darauf zu triggern. Sondern man kann mit diesem Aufruf auch einfach beliebige andere FHEM-Aktionen auslösen (sofern diese sich in einem REST-Call ausdrücken lassen). Dass also die Buttons als Reading im Shelly-FHEM-Device auftauchen ist "just for convenience".
LG
pah
Zitat von: Prof. Dr. Peter Henning am 27 November 2019, 16:53:23
Ich sehe gerade, dass Allterco da noch mehr Optionen eingebaut hat, um mit den Buttons (2 Eingänge) separate Schaltvorgänge auszulösen.
Habe das gerade noch nachgebessert, die aktuelle Version ist also 2.11.
Ich habe zwar keinen Taster zum Testen zur Hand, aber wenn man das betreffende Kommando beim Shelly in die Oberfläche einträgt:
http://<ip-adresse>/fhem?XHR=1&cmd=set%20dimmer%20button_on%200
(0 oder 1 an der letzten Stelle), registriert das Modul das korrekt.
LG
pah
Hallo pah,
das ist mir noch nicht ganz klar, wofür wird das benötigt ?
Das Modul in der neuen Version arbeitet super. Mit attr <Dimmer> widgetOverride pct:slider,1,1,100 kommt dann auch mein gewünschter Slider zum Vorschein, auch da danke für den Tip (wieder was gelernt)
Grüße Christian
Hier gibt es eine neu erkannte Inkompatibiliät der Shelly-Devices: https://forum.fhem.de/index.php/topic,106103.0.html
LG
pah
Hallo,
vielen Dank für die Mühe, die Du (ihr) in die Entwicklung des Shelly Moduls steckt. Im Moment scheint es mir so, dass es mehr Attribute in den Shelly Devices gibt, die vom Shelly Modul bisher nicht als Reading zur Verfügung gestellt werden.
Könnten nicht auch die anderen Werte (selbst, wenn es im ersten Schritt mehr Daten generiert) mit aufgenommen werden?
z.B. wifi_sta, um die Empfangsstärke zu protokollieren, temperature, overtemp., uptime, ...
Viele Grüße
Axel
Attribute sind keine Readings, und das Mitprotokollieren der Signalstärke (nicht "Empfangsstärke") stellt keine sinnvolle Messung dar.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 12 Dezember 2019, 21:18:00
Attribute sind keine Readings, und das Mitprotokollieren der Signalstärke (nicht "Empfangsstärke") stellt keine sinnvolle Messung dar.
Shellies haben aber doch Attribute, die ausgegeben werden (zumindest nennen die Entwickler es in der API Dokumentation so)?!
Warum ist das Protkollieren der Signalstärke keine sinnvolle Messung?
Mir hat ein vergleichbares Protokoll bei der Suche nach dem Verursacher einer Signalstörung schon einmal geholfen, oder, ist der vom Shelly ausgegebene Wert von wifi_sta "sinnfrei", da nicht aussagekräftig?
lg
Gernot
ZitatMir hat ein vergleichbares Protokoll bei der Suche nach dem Verursacher einer Signalstörung schon einmal geholfen
Darin liegt schon die Antwort: So etwas benötigt man in seltenen Ausnahmefällen, nicht regulär. Dann kann man sich aber auch mit einem Mausklick direkt auf die Weboberfläche des Shelly-Devices setzen und muss das nicht erst nach FHEM übertragen.
Je komplexer eine Haussteuerung wird, desto mehr sollte man auf Datensparsamkeit achten.
LG
pah
Zitat von: xitolein am 28 September 2019, 21:45:41
Hallo,
mein heutiges Problem konnte ich nur mit einem FritzBox Neustart lösen. Zwei vorherige Strom Reset führten nicht zum Erfolg. Die FritzBox und der Shelly sind Luftlinie 5 m auseinander ohne Störende Hindernisse dazwischen.
Habe heute Versucht dem Shelly eine Statische IP zu vergeben und bekam die auf dem Bild ersichtliche Fehlermeldung.
Aufgrund dessen gehen ich mal davon aus, dass der Fehler in der Fritzbox liegen muss.
Gruß
Sven
Da die Shelly Schalter nur auf 2.4 kHz senden und das in vielen Fällen schon recht voll ist und die Kanäle sich auch noch gegenseitig stören vermute ich einfach mal das hier eher das Problem ist.
Würde auch dafür sprechen, das nach dem Neustart der Fritz box es wieder ging, die sucht nach dem Neustart nämlich einen anderen Kanal (wenn die default Einstellung unter WLAN -> Funkkanal -> Funkkanal Einstellungen automatisch setzen nicht geändert wurde)
gruß
Jens
Zitat von: Prof. Dr. Peter Henning am 13 Dezember 2019, 09:02:36
...
Dann kann man sich aber auch mit einem Mausklick direkt auf die Weboberfläche des Shelly-Devices setzen und muss das nicht erst nach FHEM übertragen.
...
Echt, kann man eine log Datei jetzt über die Weboberfläche aufrufen, wie geht das?
@Axel1971: Für den Ausnahmefall geht es auch mit Fhem:
1. myUtils Datei im anlegen. z.B. /opt/fhem/FHEM/mySHELLYAttributesUtils.pm:
##############################################
# $Id: mySHELLYAttributesUtils.pm supernova1963 $
#
# myUtils für shellies vom Typ Shelly:
# http commnands an Shelly senden und Rückgabe json - string in reading x_json
# ggf. mit expandJSON readings ezeugen
package main;
use strict;
use warnings;
use POSIX;
use HttpUtils;
use JSON;
use Data::Dumper;
sub
mySHELLYAttributesUtils_Initialize($$)
{
my ($hash) = @_;
}
# Enter you functions below _this_ line.
########################################################################################
#
# ShellyHttpRequest - Aus https://wiki.fhem.de/wiki/HttpUtils#Beispiel_f.C3.BCr_HttpUtils_NonblockingGet.28.29_f.C3.BCr_Modulprogrammierer
#
########################################################################################
sub ShellyHttpRequest($$)
{
my ($name, $request) = @_;
my $hash = $defs{$name};
if ($request eq "" || !defined($request))
{
Log3 $hash, 5, $name.":mySHELLYAttributesUtils:ShellyHttpRequest($name,$request) Parameter 'request' ist nicht definiert!";
return;
}
my $httpCMND = "http://".Shelly_Credentials($hash).InternalVal($name,"TCPIP","")."/".$request;
$hash->{helper}{"request"}=$request;
my $param = {
url => $httpCMND,
timeout => 5,
hash => $hash,
method => "GET",
header => "User-Agent: TeleHeater/2.2.3\r\nAccept: application/json",
callback => \&ShellyHttpResponse
};
return HttpUtils_NonblockingGet($param);
}
########################################################################################
#
# ShellyHttpResponse - Aus https://wiki.fhem.de/wiki/HttpUtils#Beispiel_f.C3.BCr_HttpUtils_NonblockingGet.28.29_f.C3.BCr_Modulprogrammierer
#
########################################################################################
sub ShellyHttpResponse($)
{
my ($param, $err, $data) = @_;
my $hash = $param->{hash};
my $name = $hash->{NAME};
my $rc = "";
if($err ne "")
{
Log3 $name, 5, ":mySHELLYAttributesUtils:ShellyHttpRequest(<name>,>request>): Fehler bei dem URL-Aufruf: ".$param->{url}." - $err";
}
elsif($data ne "")
{
$hash->{helper}{"Data"} = $data;
my $json = new JSON;
if (!defined($defs{$name."_j2r"})) {
$rc = fhem("defmod ".$name."_j2r expandJSON ".$name.":x_json:.\{.*}");
}
readingsSingleUpdate($hash,"x_json",$data,1);
return $data;
}
}
########################################################################################
#
# Shelly_Credentials - Aus 36_Shelly.pm übernommen Author: Prof. Dr. Peter A. Henning
#
########################################################################################
########################################################################################
#
# This programm is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# The GNU General Public License can be found at
# http://www.gnu.org/copyleft/gpl.html.
# A copy is found in the textfile GPL.txt and important notices to the license
# from the author is found in LICENSE.txt distributed with these scripts.
#
# This script is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
########################################################################################
sub Shelly_Credentials($)
{
my ($hash) = @_;
my $name = $hash->{NAME};
my $user = AttrVal($name, "shellyuser", '');
return "" if(!$user);
my ($err, $pw) = getKeyValue("SHELLY_PASSWORD_$name");
if (defined($err))
{
Log3 $hash, 5, $hash->{NAME}.":mySHELLYAttributesUtils:ShellyHttpRequest(<name>,<request>) SHELLY_PASSWORD_$name ist nicht definiert!";
return ""
}
return $user.":".$pw."@";
}
2. notify oder at anlegen, das ShellyHttpRequest($NAME,'<command>') aufruft:
defmod shelly_notify_status notify shelly:relay:.* {ShellyHttpRequest($NAME,'status')}Es wird ein device vom Typ expandJSON mit dem Namen <ShellyDeviceName>_j2r angelegt, das das reading: x_json überwacht und automatisch readings aus diesem erzeugt.
3. Log anlegen, z.B.:
define shelly_wifi_sta_rssi FileLog ./log/shelly_wifi_sta_rssi-%Y-%W.log shelly:wifi_sta_rssi.*"shelly" bitte durch den device Namen ersetzten!
Fertig!
lg
Gernot
Geändert: GNU General Public License für Code aus Shelly Modul nach Belehrung durch Herrn Prof. Dr. Peter A. Henning ergänzt
Hmmm. Nach dem neuesten Pisa-Test ist das Leseverständnis wieder auf dem Rückgang.
Erstens ist die Übernahme von Code aus meinem Modul nur zulässig, wenn dabei auch die GPL-Lizensierung mit übernommen wird - dafür ist die GPL nämlich da.
Zweitens habe ich nichts von "log Datei" geschrieben. Sondern vom Zugang zu den Daten.
LG
pah
...wenn ich pah richtig verstanden habe, dann meinte er, dass, wenn man im Fehlersuchfall tatsächlich (und eigentlich macht das auch nur dann wirklich Sinn, sonst ist es aber- da bin ich einig - nice to have) den RSSI-Wert braucht, dann kann man sich über die Weboberfläche in den jeweiligen Shelly einloggen (geht bestimmt auch mit der Shelly-App) und den Wert dort anschauen...
Zitat von: Prof. Dr. Peter Henning am 14 Dezember 2019, 17:20:02
Erstens ist die Übernahme von Code aus meinem Modul nur zulässig, wenn dabei auch die GPL-Lizensierung mit übernommen wird - dafür ist die GPL nämlich da.
Ich bitte vielmals um Entschuldigung und habe umgehend den Beitrag geändert.
lg
Gernot
Zitat von: cs-online am 14 Dezember 2019, 17:41:47
...wenn ich pah richtig verstanden habe, dann meinte er, dass, wenn man im Fehlersuchfall tatsächlich (und eigentlich macht das auch nur dann wirklich Sinn, sonst ist es aber- da bin ich einig - nice to have) den RSSI-Wert braucht, dann kann man sich über die Weboberfläche in den jeweiligen Shelly einloggen (geht bestimmt auch mit der Shelly-App) und den Wert dort anschauen...
Ich habe doch nur @Axel1971 meinen laienhaften Lösungsansatz eines der gewünschten Protokolle mit fhem umzusetzen, - ohne Shelly Moduländerungen -, vorgestellt. Bei einem solchen Signalstörung hat es mir geholfen, ein Protokoll über längere Zeit zu beobachten.
lg
Gernot
...alles gut, ich hatte nur das Gefühl, dass Ihr aneinander vorbei geschrieben habt... :-)
Zitat von: supernova1963 am 14 Dezember 2019, 14:27:56
@Axel1971: Für den Ausnahmefall geht es auch mit Fhem:
Danke
Hallo pah,
es scheint noch eine kleine Korrektur in der CommandRef notwendig zu sein:
set <name> hsv <hue value 0..360>,<saturation value 0..1>,<brightness value 0..1> Der Hue-Wert sollte hierbei auch als Wert zwischen 0 und 1und nicht zwischen 0 und 360 angegeben werden, da ansonsten eine Fehlermeldung im Logfile darauf hinweist
Ich wurde an anderer Stelle darauf aufmerksam gemacht, dies als Fehler zu melden:
Zitat von: justme1968 am 22 Dezember 2019, 16:06:58
da unterschiedliche geräte unterschiedliche bereiche verwenden (0-100, 0-359, 0-360, 0-65535) erwartet Color::hsv2rgb die werte im bereich 0..1. auch hsv. d.h. du musst deinen wertebereich auf 0..1 skalieren.
da dies scheinbar in einem modul passiert muss du das dort als fehler melden..
Funktionieren tut's trotzdem, die Meldung verwirrt nur ein wenig.
cg,
al
Ich werde mal sehen, dass ich diese Meldung tatsächlich unterdrücke.
Allerdings werde ich am Wert im Modul nichts ändern, die Aufforderung
Zitatda dies scheinbar in einem modul passiert muss du das dort als fehler melden..
ist Käse. Derjenige sollte mal meine Computergrafik-Vorlesung besuchen.
Hue wird als zyklische Variable im Wertebereich 0..360 angegeben, fertig.
LG
pah
Edit: ... wobei 360° = Rot derselbe Farbton wie 0° ist.
Hallo
Ich habe da ein Problem und komme irgendwie nicht weiter vielleicht hat der ein oder andere ein Tipp für mich.
Ich habe an einen Shelly 1 einen normalen Lichtschalter am SW Eingang angeschlossen. Der Schalter soll über Actions nur Button on oder off an FHEM senden. Leider klappt dieses nicht.
Der Shelly ist auf Button Type Detached Switch eingestellt. URL für zum Beispiel Button on ist:
https://user:password@192.168.0.xx:8083/fhem?XHR=1&cmd=set%20EZ_S_LiET%20button_on%20&fwcsrf=token
Gebe ich die URL im Browser ein wird das reading button auf on gesetzt.
Wenn ich den Schalter betätigen und im Browser mit der IPdesShelly/status gucke wir Input auch von 0 auf 1 geändert.
Nur leider kommt im FHEM nichts an.
Die Frage ist wie kann ich es Überprüfen wo es hängt?
VG Alex
Ich vermute: der Shelly kann kein HTTPS.
Das vermute ich auch schon fast allerdings ist merkwürdig das es gestern einrichten und bei einen anderen Shelly hin und wieder Mal geht.
Ok es steht denke ich fest es liegt am https.
Es verwundet mich aber schon das es kurzzeitig funtioniert hat trotz https
Ich habe einen RGBW2. Jemand eine Idee, wie die die LED's zum blinken bekomme?
Aus FHEM heraus, oder mit den eingebauten Kommandos?
LG
pah
Egal, klar könnte man ein fhem ein an,aus,an,aus schalten. Da wird der Code aber unübersichtlich. Vllt gibt es einen besseren Weg. Oder per MQTT.
Bei Wifilight gibt es z.B.
set LED_.* HSV 0,100,100 0 q;set LED_.* HSV 0,100,100 2 q;set LED_.* HSV 120,100,0 0 q;set LED_.* HSV 120,100,0 1 q alarm 100
Zitat von: TWART016 am 21 Januar 2020, 15:14:03
Ich habe einen RGBW2. Jemand eine Idee, wie die die LED's zum blinken bekomme?
probier's mal so:
set <name> config effect 3VG,
al
Zitat von: Prof. Dr. Peter Henning am 23 Mai 2019, 16:25:16
Ich habe gerade Version 2.01 eingecheckt, mit den genannten Ergänzungen. Achtung: energy als Reading (in Ws) gibt es nicht bei allen Devices, z.B. nicht beim RGBW2
Im Prinzip müsste ich jetzt noch den Befehl "get ... registers" anpassen. Das muss aber warten, habe außer FHEM und Golfspielen noch anderes zu erledigen...
LG
pah
Kurze Frage zum Reading energy. Laut API gibt der Shelly1PM die Energie Watt*Min. Nach der Umrechnung im Modul sind es doch Wh und nicht Ws wie beschrieben. ((total/6)/10)
Ist das so richtig oder stehe ich gerad komplett auf den Schlauch.
VG Alex
Ich schreibs ja nur ungerne, aber das ist vollkommen richtig - es muss Wh lauten.
LG
pah
Hallo,
Ist geplant das Shelly em und denn Tür und Fenster Kontakt zu implementieren ?
Hallo pah
Ich habe heute meinen Ersten Shelly 2.5 mit hilfe deines Moduls in Fhem eingebunden. Leider stehe ich noch vor einem Problem, dass ich irgendwie nicht gelöst bekomme. Ich steuere meine Fhem Installation über Apple Homekit via Homebridge. Wenn ich nun in Homebridge den Shelly ansteuere funktioniert das tip top. Wenn ich jedoch direkt über Fhem oder den Switch Input am Shelly schalte, wird mir der Status in Homekit nicht aktualisiert.
Hier die list vom Shally:
Internals:
DEF 172.21.0.50
DURATION 0
FUUID 5e349106-f33f-ddec-0d75-78c950a0f4bc1b10
INTERVAL 0
NAME Ganglicht
NR 74
STATE off
TCPIP 172.21.0.50
TYPE Shelly
READINGS:
2020-01-31 21:41:42 cloud disabled
2020-01-31 21:47:41 config mode=relay [channel s]
2020-02-01 02:08:16 energy_0 55.4
2020-01-31 23:03:03 energy_1 0
2020-01-31 21:41:42 firmware v1.5.9
2020-02-01 02:08:08 network <html>connected to <a href="http://172.21.0.50">172.21.0.50</a></html>
2020-02-01 02:09:41 overpower_0 0
2020-02-01 02:06:11 overpower_1 0
2020-02-01 02:09:42 power_0 0
2020-01-31 23:03:03 power_1 0
2020-02-01 02:09:41 relay_0 off
2020-02-01 02:06:11 relay_1 off
2020-02-01 02:09:41 state OK
Attributes:
defchannel 0
interval 0
mode relay
model shelly2.5
room Homekit
stateFormat relay_0
verbose 0
hab ich etwas übersehen?
LG
Sergio
Zitat von: ScacchiSL am 01 Februar 2020, 02:19:45
hab ich etwas übersehen?
LG
Sergio
Bin zwar nicht pah ;)
Antworte aber trotzdem mal:
homebridgeMapping...
Der Zustand steht (verm.) in keinem Reading welches homebridge automatisch "erkennt" (bei on/off wohl state)...
Daher mittels homebridgeMapping eben homebridge "mitteilen"...
Gruß, Joachim
Dir ist schon klar, dass Du mit Interval = 0 keine automatischen Status-Updates vom Shelly zum FHEM bekommst?
ZitatDir ist schon klar, dass Du mit Interval = 0 keine automatischen Status-Updates vom Shelly zum FHEM bekommst?
Unsinn. Das Interval regelt lediglich das Polling durch FHEM. Wenn man den Shelly richtig konfiguriert hat, führt er bei Statusänderungen einen REST-Call an FHEM durch und ändert dort das Reading.
LG
pah
ZitathomebridgeMapping...
Der Zustand steht (verm.) in keinem Reading welches homebridge automatisch "erkennt" (bei on/off wohl state)...
Daher mittels homebridgeMapping eben homebridge "mitteilen"...
Hallo Joachim
ja ich gehe auch schwer davon aus, dass Homebridge das state Reading ausliest um den Schaltzustand des Shellys aus zu werten und wenn da nur OK steht, kann Homebridge natürlich nicht viel damit anfangen. Ich denke eigentlich müsste ich das Mapping so machen, dass der state = dem Zustand von relay_0 ist. Ich hab mich gestern bereits etwas mit homebridgeMapping versucht. Leider hab ich bis jetzt keine Doku gefunden, bei der ich schlau geworden bin wie ich dieses schreiben soll. Kannst du mir da bitte weiterhelfen?
ZitatDir ist schon klar, dass Du mit Interval = 0 keine automatischen Status-Updates vom Shelly zum FHEM bekommst?
@wk Danke für die Info. hab das Attribut wieder rausgelöscht
LG
Sergio
Zitat von: ScacchiSL am 01 Februar 2020, 10:49:14
Leider hab ich bis jetzt keine Doku gefunden, bei der ich schlau geworden bin wie ich dieses schreiben soll. Kannst du mir da bitte weiterhelfen?
Habe kein Shelly aber hier solltest du was finden bzw. ist das die Doku die du nicht finden konntest:
https://wiki.fhem.de/wiki/Homebridge_User_Configs
https://wiki.fhem.de/wiki/Alexa_und_Mappings
Hinweis: homebridgeMapping "stammt" von homebridge/homekit wird aber mittlerweile von verschiedenen "Diensten" verwendet: homebridge, alexa-fhem, gassistant, ...
Also überall dort kannst du suchen, vielleicht gibt es sogar schon was bzgl. Shelly...
...ansonsten eben selber adaptieren...
Gruß, Joachim
Hallo PAH,
zunächst herzlichen Dank für die Arbeit am Modul.
Ist denn bereits absehbar, wann die Tür-/Fenstersensoren integriert werden?
Eigentlich hat Shelly ja ein deutlich bessere Firmware angekündigt, die auf eine Kipp- und Vibrationserkennung realisieren soll, infolge der regelmäßigen Verschiebung beim Produktstart und der ausbleibenden Antwort vom Support erwarte ich hier keine zeitnahe Veränderung.
Herzlichen Dank vorab.
LG,
muede
ZitatIst denn bereits absehbar, wann die Tür-/Fenstersensoren integriert werden?
Nö.
LG
pah
Hallo PAH,
es gibt in Homematic ein Reading energyCalc, dieses zählt auch dann noch weiter hoch, wenn das Device stromlos war. Bei den Shellys habe ich so etwas nachgebaut mit
attr <device> userReadings energyCalc:energy.* monotonic {ReadingsVal("<device>","energy",0)}
Entsprechendes habe ich für die 2.5 bzw. 4pro mit energy_n und energyCalc_n
Könnte man das nicht defaultmäßig mit in das Modul 36_Shelly.pm reinnehmen?
Zitat von: justcallmeal am 22 Januar 2020, 22:31:24
probier's mal so:
set <name> config effect 3
Danke, sieht gut aus. Was bedeutet der Channel?
effect=0 [channel 0]
Zitat
Könnte man das nicht defaultmäßig mit in das Modul 36_Shelly.pm reinnehmen?
Nein. Man kann nicht jede Funktionalität, die anders erbracht werden kann, in jedes Modul mit aufnehmen.
LG
pah
Zitat von: ScacchiSL am 01 Februar 2020, 02:19:45
Hallo pah
Ich habe heute meinen Ersten Shelly 2.5 mit hilfe deines Moduls in Fhem eingebunden. Leider stehe ich noch vor einem Problem, dass ich irgendwie nicht gelöst bekomme. Ich steuere meine Fhem Installation über Apple Homekit via Homebridge. Wenn ich nun in Homebridge den Shelly ansteuere funktioniert das tip top. Wenn ich jedoch direkt über Fhem oder den Switch Input am Shelly schalte, wird mir der Status in Homekit nicht aktualisiert.
Hier die list vom Shally:
hab ich etwas übersehen?
LG
Sergio
Ich habe nur Shelly1 im Einsatz, dort verwende ich folgendes Homebridge mapping:
On=relay,valueOff=off,valueOn=on,cmdOff=off,cmdOn=onProbier das mal als Grundlage...
Gruß
Jan
Hallo, ich bin neu hier.. habe heute meine ersten beiden Shelly's zum testen bekommen.. wollte die dann heute eigentlich auch mit Tasmota flashen.
Jetzt lese ich aber immer das ich auch die original Firmware behalten kann, weil diese auch mqtt kann.
Meine sonoff minis sind mit tasmota geflasht. Da hab ich den Sinn verstanden damit man von der Cloud weg kommt.. aber bei den shellys kann man ja die cloud abstellen.. wo ist jetzt der Vorteil ? Sorry.. hoffe ich bin richtig.
Gruß Marcell
Gesendet von iPhone mit Tapatalk Pro
Zitat von: Kellerkind86 am 06 Februar 2020, 14:50:23
Sorry.. hoffe ich bin richtig.
No. Ausweislich des ersten Beitrags und (!) des Thread-Titels geht es hier um ein bestimmtes FHEM-Modul, nicht um die Hardware.
Das hier besprochene Modul dient u.a. auch dazu, zusätzliche Infrastruktur (MQTT-Server) zu vermeiden.
Bitte anderen Thread zur Hardware nutzen oder ggf. neuen im Anfängerbereich erstellen (oder einfach MQTT aktivieren und mit der MQTT-Implementierung deiner Wahl nutzen; welche Einbindungsvariante man nimmt, ist (fast) Geschmackssache, und wer sich sowieso in MQTT (optimalerweise in MQTT2_DEVICE) bei anderen firmwares eingearbeitet hat, wird das auch mit der shelly-firmware schaffen, korrektes Lesen (!) vorausgesetzt).
(Ich werde nicht auf weitere Rückfragen von dir zu MQTT hier reagieren! Es ist OT!)
Guten Morgen zusammen,
auch ich habe dank dieses tollen Moduls mein ersten Shelly 2.5 als Rolladensteuerungsmodul in Betrieb genommen. Klappt out of the box wirklich toll.
Zwei Verständnisfragen habe ich dennoch:
1.) wurde weiter oben schon angesprochen, aber ist mir noch unklar:
Mein Shelly ist per IP_Adresse definiert ohne MQTT. Wie erhält FHEM Informationen vom Shelly, wenn unabhängig von FHEM, z.B. über angeklemmte Taster, eine Einstellung am Shelly getätigt wird?
Ich sehe bei mir, dass die Statusänderungen zwar nicht in Echtzeit gesendet werden, aber binnen eines recht kurzen Zeitraums erhält FHEM die Statusänderung dennoch.
Laut Wiki Eintrag :
ZitatGegen die Nutzung dieses Moduls mit den Shelly-Devices spricht, dass damit der Aktor nicht im Stande ist, irgendwelche Zustandsänderungen von sich aus an FHEM zu melden.
dürfte das gar nicht funktionieren, es sei denn man nutzt das Attribut "intervall" zum pollen.
Zitat von: Prof. Dr. Peter Henning am 01 Februar 2020, 09:55:02
Unsinn. Das Interval regelt lediglich das Polling durch FHEM. Wenn man den Shelly richtig konfiguriert hat, führt er bei Statusänderungen einen REST-Call an FHEM durch und ändert dort das Reading.
Welcher Teil der Shelly-Konfiguration ist dafür zuständig?
Zusammenfassend: es klappt bei mir prinzipiell, aber ich möchte mein Verständnis dafür entwickeln ;)
2.)
In den Shelly-Device Readings gibt es einmal "pct" und einmal "position". Worin unterscheiden sich diese beiden Readings, abgesehen dass "Position" zusätzlich "open" und "closed" ausgeben kann?
Hallo,
also, wenn ich das richtig verstanden habe, fragt das Modul schon in gewissem Intervall alle Parameter ab. Wenn man allerdings will, dass FHEM sofort mitbekommt, dass eine Taste gedrückt ist, dann muss man im Shelly die Links auf FHEM bei den Tastendrücken hinterlegen. Bei mir wird der Status auch kurz nach dem Schalten aktualisiert, ohne Polling/Intervall
Grüße Christian
Zitat von: cs-online am 07 Februar 2020, 12:11:23
dann muss man im Shelly die Links auf FHEM bei den Tastendrücken hinterlegen.
Kannst Du das etwas näher beschreiben?
Dieser Hinweis
ZitatGegen die Nutzung dieses Moduls mit den Shelly-Devices spricht, dass damit der Aktor nicht im Stande ist, irgendwelche Zustandsänderungen von sich aus an FHEM zu melden.
im Wiki ist veraltet und wurde gerade entfernt. Siehe Commandref zum 36_Shelly.pm, da steht alles drin.
LG
pah
Zitat von: Dracolein am 07 Februar 2020, 12:36:03
Kannst Du das etwas näher beschreiben?
Hi,
Du kannst Fhem-(URL-)Befehle im Shelly selbst hinterlegen --> Einstellungen unter "Actions" - "Output switched off URL" - dort die Checkbox "Enable" aktivieren und dann entsprechende URL-Befehle eingeben wie z.B.
http://192.xxx.xxx.xx:8083/fhem?cmd=set <device> onvg,
al
Danke für die Info.
Die URLs irritieren mich derzeit immer noch.
In meinem Fall: Shelly 2.5 als "roller", die Shelly GUI bietet zwar die Möglichkeit der URL-Vorgabe, jedoch sind die 3 Zeilen definiert mit
ZitatUrl to be hit when the roller opens
ZitatUrl to be hit when the roller closes
ZitatUrl to be hit when the roller stops
Dazu passen die Erläuterungen in der CommandRef nicht ganz.
Und nu? :o :-[
Hmmm. Gehirn anwerfen und selber denken ?
LG
pah
Danke für die "Hilfe" ::)
Es tut mir leid, dass mein Posting den Eindruck vermittelte, dass ich als fauler User der Einfachheit lieber nachfrage, anstelle mein Gehirn zu bemühen.
Ich hatte gestern abend um 23:00 Uhr nichts anderes zu tun, als Euch mit unqualifizierten Fragen zu provozieren.
Wenn ich auf Erfahrung zurückgreifen könnte, würde ich es tun. Dem ist leider nicht so. Leider wird in der CommandRef meine o.g. Konfiguration nicht erwähnt.
Zitat
In Shelly switch devices or the Shelly dimmer device one may set URL values that are "hit" when the input or output status changes. Here one must set
For Button switched ON url: http://<FHEM IP address>:<Port>/fhem?XHR=1&cmd=set%20<Devicename>%20button_on%20[<channel>]
For Button switched OFF url: http://<FHEM IP address>:<Port>/fhem?XHR=1&cmd=set%20<Devicename>%20button_off%20[<channel>]
For Output switched ON url: http://<FHEM IP address>:<Port>/fhem?XHR=1&cmd=set%20<Devicename>%20out_on%20[<channel>]
For Output switched OFF url: http://<FHEM IP address>:<Port>/fhem?XHR=1&cmd=set%20<Devicename>%20out_off%20[<channel>]
Kein roller blind device erwähnt.
Channel 0 / 1 hat der Shelly im "Roller" Mode lt. GUI nicht, oder ist channel0/1 = rauf/runter ?
Ich benötige keine Statusupdates der Buttons. Es würde ausreichen, wenn Aktivität der Rolläden registriert wird.
"Url to be hit when the roller stops" = URL für Output switched off ?
"Url to be hit when the roller closes/opens" = URL Output switched on ?
Falls diese Annahme zutrifft, ist mir immer noch die Angabe des Channels schleierhaft
Vorab trotzdem schönen Dank für Hilfestellung
edit:
habe inzwischen so ziemlich jede Kombination der URLs durchprobiert; alles ohne spürbare Reaktion seitens FHEM...
Es kann an FHEM jedes beliebige Kommando übermittelt werden, wenn eines der drei Ereignisse "Roller Open", "Roller Close" oder "Roller Stop" durch einen Button am Shelly 2.5 ausgelöst wurde. Damit soll natürlich NICHT ein weiterer Open, Close oder Stop-Befehl von FHEM an den Shelly gestartet werden - sondern nur ein Reading aktualisiert werden, das ggf. sonst erst beim nächsten Polling abgefragt wird.
Man könnte also problemlos für jede der drei "URL to be hit" eintragen
http://<FHEM IP address>:<Port>/fhem?XHR=1&cmd=get%20<Devicename>%20status
Jeder Tastendruck wird dann eine Statusabfrage durch FHEM initiieren. Evtl. kann man in den Befehl auch noch eine Verzögerung einbauen.
LG
pah
Ich danke Dir, das werde ich probieren. Die Zeitverzögerung werde ich mithilfe eines Notify erstellen, sodass z.B. 15 Sekunden nach Schalterbetätigung FHEM eine Statusabfrage an den Shelly sendet und aktuelle Zustandsinformationen erhält. Mal sehen.
Herzlichen Dank für die Hilfestellung.
Du könntest auch einfach ein kurzes sleep in den zu sendenden Befehl einbauen.
Zitat von: marvin78 am 11 Februar 2020, 15:20:01
Du könntest auch einfach ein kurzes sleep in den zu sendenden Befehl einbauen.
Blockiert "sleep" während seiner Laufzeit nicht FHEM vollständig, bis die Zeit abgelaufen ist?
Hast du die Doku zu sleep (FHEM-sleep) gelesen?
Zitat von: marvin78 am 11 Februar 2020, 15:47:57
Hast du die Doku zu sleep (FHEM-sleep) gelesen?
Danke, habe ich, ja.
Ich habe heute abend das Ganze ausprobiert, URL wie folgt:
Zitathttp://192.168.178.83:8083/fhem?XHR=1&cmd=get%20shelly1%20status
Beim Aktivieren des Shellys per angeklemmtem Schalter empfängt FHEM kein Event im Eventmonitor. Die IP-Adresse und der Port stimmen. Der Befehl
get shelly1 status innerhalb FHEM funktioniert auch zuverlässig.
Muss seitens FHEM hier noch irgend etwas aktiviert / "geöffnet" werden, damit das System "empfangsbereit" ist ? Das normale Interval-Polling klappt, die Steuerung via FHEM klappt auch, es kann also nicht an der Verbindung liegen.
Moin.
Ich sehe keinen cfrs-token in deinem Link. Sicher, das du den nicht brauchst?
Gesendet von iPhone mit Tapatalk
Hi,
ich habe Deinen Link einige Seiten vorher verwendet und mein FHEM Kennwort + Username + meinen fest definierten Token eingegeben.
http://username:kennwort@192.168.178.83:8083/fhem?cmd=get%20[b]<[/b]shelly1%20status&fwcsrf=meintoken&XHR=1
Die URL habe ich in allen 3 Zeilen des Shelly eingetragen. Jedoch keine Eventerkennung im Eventmonitor zu sehen.
Und jetzt, wo ich dies Posting verfasse, sehe ich meinen Schreibfehler ::) ::) ::)
Fazit: jetzt klappt es. Ein Sleep Befehl ist sogar unnötig, da sowohl der Start wie auch der Stop jeweils ein Event senden. D.h. sobald der Rolladen stoppt, wird in meiner Visualisierung das Symbol unmittelbar entsprechend der Rolladenstellung geändert. Ganz ohne Wartezeit (wie bisher)
Tip: ggf. Deine URL in den Wiki-Eintrag hinzufügen, die Info kann nützlich sein.
Danke für die Hilfe.
Hallo,
meine Shelly 1 geht nach jedem Neuladen der fhem.cfg auf error (und bleibt dort).
Nach einem set <shelly> password xxx steht das Passwort in der Datei uniqueID, die Verbindung zum Gerät kann aufgebaut werden und Schaltbefehle funktionieren.
Nach einem Restart von fhem immer noch.
Aber nach jedem Edit Files -> fhem.cfg -> Save (auch ohne jede Änderung) ist die entsprechende Passwort-Zeile nicht mehr in der Datei uniqueID, das Gerät steht auf error.
Das Abschalten der Authentifizierung bei der Shelly hilft natürlich.
Woran kann es liegen, dass das gespeicherte Passwort nach jedem Neuladen der fhem.cfg verschwindet? Das Passwort enthält keine Sonderzeichen.
Danke, Stefan
Vorerst könnte es helfen, die config nicht zu editieren. Warum machst du das und warum so oft? Es gibt kaum Gründe für direktes editieren.
Hallo,
hat schon jemand den H&T über dieses Modul in FHEM integriert ?
Nein. Und das wird auch nicht geschehen.
pah
Hallo,
vielen Dank für das Modul.
Bin neu bei shelly und habe hier jetzt einen shelly-dimmer.
Von enocean, hue und homematic bin ich es gewöhnt, dass bei dem Befehl
set Lampe_XY pct [0-100%]
die Lampe an geht und auf den entsprechenden Wert dimmt.
Bei dem shelly-Modul passiert das aber nicht.
Auf der geräteeigenen Webseite ist die von mir beschriebene Funktion gegeben.
Gibt es einen bestimmten Grund, dass diese Funktion im Modul nicht vorhanden ist?
Wie handhabt ihr die Ansteuerung des Dimmers? Zwei Befehle absenden?
Vielen Dank für eine Rückmeldung.
bis denn
SouzA
Zitat von: SouzA am 12 März 2020, 22:33:24
Wie handhabt ihr die Ansteuerung des Dimmers? Zwei Befehle absenden?
Genau, ich gebe da zwei Befehle ein. Erst einschalten, dann dimmen
Guido
Sent from my iPad using Tapatalk
Benutzt jemand den shelly dimmer in Verbindung mit homebridge und apple home?
Wäre interessant hier mal das homebridge-mapping zu posten.
Ich nutze den Dimmer mit Alexa, allerdings Custom Skill, mit genericDeviceType switch, ich kann dann sagen "schalte Lampe ein" und dann "stelle Lampe auf 50%", das funktioniert einwandfrei.
Grüße
Christian
Zitat von: cs-online am 13 März 2020, 12:32:19
Ich nutze den Dimmer mit Alexa, allerdings Custom Skill, mit genericDeviceType switch, ich kann dann sagen "schalte Lampe ein" und dann "stelle Lampe auf 50%", das funktioniert einwandfrei.
Grüße
Christian
Genau das hatte ich bisher nicht. Bei allen anderen Lampen funktioniert "dimme Lampe auf 50%" und die geht auf 50% an.
Schade, aber das muss ja irgendwie was mit dem Modul zu tun haben, da es vom Gerät her ja unterstützt wird (Webseite).
Bis denn
SouzA
Zitatirgendwie was mit dem Modul
Sicher. Es steht jedem frei, einen REST-Call an das Device abzusenden, der Einschalten auf einen bestimmten Helligkeitswert zusammenfasst. Hier die Anleitung:
http://shelly-api-docs.shelly.cloud/#shelly-dimmer-sl
pah
Zitat von: Prof. Dr. Peter Henning am 13 März 2020, 18:32:07
Sicher. Es steht jedem frei, einen REST-Call an das Device abzusenden, der Einschalten auf einen bestimmten Helligkeitswert zusammenfasst. Hier die Anleitung:
http://shelly-api-docs.shelly.cloud/#shelly-dimmer-sl
pah
Hi,
vielen Dank für den Link.
Jetzt hat sich noch eine weitere Frage ergeben...
Wie kann ich in dem von shelly-Modul erstelltem Device einen Schieberegler darstellen?
Wenn ich das attr webCmd um pct erweitere (pct:on:off) steht da dann zwar "pct on off" aber dimmen kann man damit dann nicht.
Gibt es dazu irgendwie eine Möglichkeit?
Vielen Dank und bis denn
SouzA
Zitat von: cs-online am 13 März 2020, 12:32:19
Ich nutze den Dimmer mit Alexa, allerdings Custom Skill, mit genericDeviceType switch, ich kann dann sagen "schalte Lampe ein" und dann "stelle Lampe auf 50%", das funktioniert einwandfrei.
Grüße
Christian
Hi,
ich habe jetzt meinen shelly dimmer in betrieb und selbst ohne homebridge mapping geht da schon fast alles.
"Problematisch" ist teilweise noch die direkte Bedienung am Schalter. Alles was ich dort mache kommt zwar sauber in FHEM an, aber teilweise nicht in Apple Home.
Folgendes habe ich als problematisch identifiziert:
Dimmer ist eingeschaltet und wird direkt am Schalter ausgeschaltet. FHEM Stellt den Zustand richtig dar, in Apple Home bleibt die Lampe mit dem entsprechenden Zahlen wert eingeschaltet
Umgekehrter Fall, Dimmer ist ausgeschaltet und wird direkt am Schalter eingeschaltet. FHEM Stellt den Zustand richtig mit dem entsprechenden dammwert dar, in Apple Home bleibt die Lampe ausgeschaltet . Stellt man nun am Schalter selbst einen helleren oder dunkleren Dimmwert ein (taster gedrückt halten) so wird dies korrekt in FHEM aktualisiert. Dies kommt dann in apple home an - dann wird auch die Darstellung des Schaltzustands richtig aktualisiert .
Beispiel: Apple home zeigt den Dimmer als "aus". Tatsächlich ist er mit 25% eingeschaltet, Taster wird gedrückt, Dimmer geht auf 50% - werte erscheinen in fhem. Aktualisierung in Apple home erfolgt - Darstellung springt von "aus" auf "ein 50%"
Das shelly Modul für den Dimmer macht hier einen super Job, aber vielleicht haben andere shelly user ja auch diesen Effekt.
@SouzA: Siehe Anlage.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 19 März 2020, 19:27:34
@SouzA: Siehe Anlage.
LG
pah
Vielen Dank,
das kannte ich noch nicht... bzw. bisher bestand noch nicht die Notwendigkeit...
Falls es jemanden interessiert:
attr webCmd pct:on:off
attr widgetOverride pct:slider,0,5,100
Thx und bis denn
SouzA
Zitatdas kannte ich noch nicht
Darum schreib ich ja Bücher darüber ...
LG
pah
Wenn ich über alles, was ich nicht kenne, Bücher lesen würde, hätte ich keine Zeit mehr auf das Klo zu gehen.
Es wäre auch einfach in der commandref nachzulesen. Dazu ist kein Buch notwendig.
ZitatEs wäre auch einfach in der commandref nachzulesen
Darum wird auch niemand gezwungen, das Buch zu lesen. Allerdings glaube ich, in der didaktischen und sprachlichen Qualität ebenso wie im logischen Aufbau gewisse Unterschiede zu sehen...
LG
pah
Zitat von: Prof. Dr. Peter Henning am 20 März 2020, 07:44:01
gewisse Unterschiede
Schade, dass ich nur einmal zustimmen kann.
Zitat von: marvin78 am 20 März 2020, 06:23:03
Es wäre auch einfach in der commandref nachzulesen. Dazu ist kein Buch notwendig.
*offtopic on*
Wie kommt man in der commandref von meinem Problem zu widgetOverride?
Und wenn man sich die ref dazu anschaut, kommen da eher noch mehr Fragen als Antworten.
Ich erwarte keine Antwort...
*offtopic off*
Bis denn
SouzA
Tja. Es ging mir nur darum herauszustellen, dass man das nicht NUR in einem Buch nachlesen kann, das nicht direkt zur Dokumentation von FHEM gehört, es also kein Zaubertrick ist, der undokumentiert ist.
Dass es eine Berechtigung für das Buch gibt, habe ich weder angezweifelt, noch kann man das meinem Beitrag entnehmen oder dort hinein interpretieren.
No offense taken.
pah
Hallo Peter,
habe seit längerer Zeit bei jedem Neustart folgende Meldung im LOG:
2020.04.13 10:24:14 1: Including ./log/fhem.save
2020.04.13 10:24:14 1: [Shelly_Attr] setting the mode attribute only works for model=shelly2|shelly2.5|shellyrgbw
2020.04.13 10:24:14 1: [Shelly_Attr] setting the mode attribute only works for model=shelly2|shelly2.5|shellyrgbw
2020.04.13 10:24:14 1: [Shelly_Attr] setting the mode attribute only works for model=shelly2|shelly2.5|shellyrgbw
2020.04.13 10:24:14 1: [Shelly_Attr] setting the mode attribute only works for model=shelly2|shelly2.5|shellyrgbw
...hab ich bei meinen 2.5ern auch...
Öh, habe ich bei 8 Shelly 2.5 nicht...
Versionsnummer?
LG
pah
Zitat von: Prof. Dr. Peter Henning am 14 April 2020, 04:51:24
Öh, habe ich bei 8 Shelly 2.5 nicht...
Versionsnummer?
FVERSION 36_Shelly.pm:v2.11.0-s20605/2019-11-27
Hallo,
erstmal vielen Dank für das tolle Modul, funktioniert alles einwandfrei.
Wäre es vielleicht noch möglich beim shellydimmer auch die register einzufügen, das wäre super!
Gruß Daniel
Hallo PAH,
meine Version ist
36_Shelly.pm 20605 2019-11-27 15:46:54Z phenning
so wie mit Update ausgeliefert, vermute ich...
Grüße
Christian
Zitat von: Dracolein am 12 Februar 2020, 18:03:32
http://username:kennwort@192.168.178.83:8083/fhem?cmd=get%20[b]<[/b]shelly1%20status&fwcsrf=meintoken&XHR=1
Die URL habe ich in allen 3 Zeilen des Shelly eingetragen. Jedoch keine Eventerkennung im Eventmonitor zu sehen.
Und jetzt, wo ich dies Posting verfasse, sehe ich meinen Schreibfehler ::) ::) ::)
Fazit: jetzt klappt es. Ein Sleep Befehl ist sogar unnötig, da sowohl der Start wie auch der Stop jeweils ein Event senden. D.h. sobald der Rolladen stoppt, wird in meiner Visualisierung das Symbol unmittelbar entsprechend der Rolladenstellung geändert. Ganz ohne Wartezeit (wie bisher)
Hi, ich habe mir 2 Shelly 2.5 zugelegt und heute eingerichtet. Bis jetzt war alles sehr leicht. Klasse.
Nur den sofortigen Status bekomme ich per Rest-Link nicht hin.
Ich nutze aus dem obrigen Post:
https://user:passwort@fhem2:8083/fhem?cmd=get%20
<Rollo_Hausflur%20status&fwcsrf=meinToken&XHR=1
Klappt aber nicht...und ein Log gibt es leider nicht.
Was mache ich falsch? Kann das an dem HTTPS liegen?
Danke für einen Hinweis!
VG
Christian
PS: Danke für das Modul! Klasse!
Zitat von: Chris8888 am 20 April 2020, 21:57:12
Hi, ich habe mir 2 Shelly 2.5 zugelegt und heute eingerichtet. Bis jetzt war alles sehr leicht. Klasse.
Nur den sofortigen Status bekomme ich per Rest-Link nicht hin.
Ich nutze aus dem obrigen Post:
https://user:passwort@fhem2:8083/fhem?cmd=get%20<Rollo_Hausflur%20status&fwcsrf=meinToken&XHR=1
Klappt aber nicht...und ein Log gibt es leider nicht.
Was mache ich falsch? Kann das an dem HTTPS liegen?
Danke für einen Hinweis!
VG
Christian
PS: Danke für das Modul! Klasse!
Ich sehe tatsächlich zwei Unterschiede zwischen deinem und meinem Link: das https UND das "<" vor Rollo.
Bis denn
SouzA
Zitat von: majestro84 am 18 Januar 2020, 21:12:38
Ok es steht denke ich fest es liegt am https.
Es verwundet mich aber schon das es kurzzeitig funtioniert hat trotz https
Guck Mal ab Beitrag 440 hatte das selbe Problem mit https.
VG Alex
Hallo, bekomme diese Meldung:
PERL WARNING: Argument "open" isn't numeric in numeric gt (>) at (eval 373823) line 1
Im DIOF sieht es so aus:
([MQTT2_publishing_client:PAC] < 450 and not [Jalo_EG_2:position]eq"open" and not [Jalo_EG_2:position]eq"closed") (set Jalo_EG_2 open) DOELSEIF ([netatmo_D70_ee_50_04_a2_32:temperature] >22 and [MQTT2_publishing_client:PAC] > 1800 and not [Jalo_EG_2:position]eq "closed" and not [Jalo_EG_2:position]>45 )(set Jalo_EG_2 pct 46)
Zitat von: majestro84 am 21 April 2020, 07:41:50
Guck Mal ab Beitrag 440 hatte das selbe Problem mit https.
VG Alex
Danke. Werde ich mal umstellen und testen...
Hi,
ich verwende seit gefühlt ewig einen shelly rgbw2 für mein Treppenlicht.
Da ich nun noch einen Bewegungsmelder mit eingebaut habe, wollte ich darüber die Helligkeit
wenn Bewegung detektiert wurde auf 100% stellen.
Allerdings passiert nix wenn ich
set Treppenlicht pct 100
eingebe.
Passt doch aber so, oder?
Der shelly ist so angelegt:
defmod Treppenlicht Shelly x.x.x.x
attr Treppenlicht mode color
attr Treppenlicht model shellyrgbw
attr Treppenlicht room 1_Treppe
attr Treppenlicht webCmd rgb
attr Treppenlicht widgetOverride rgb:colorpicker,rgb
Vielen dank schonmal!
LG Manuel
Moin,
https://forum.fhem.de/index.php/topic,93251.msg1031431.html#msg1031431 (https://forum.fhem.de/index.php/topic,93251.msg1031431.html#msg1031431)
und folgend.
Du brauchst zwei Befehle.
Bis denn
SouzA
Hi SouzA,
die Lampe ist bereits eingeschaltet.
Aber trotzdem funktioniert das dimmen nicht :-[
Ich nutze zuerst
set Treppenlicht on
Dadurch geht der LED-Strip schonmal an.
Aber ein
set Treppenlicht pct 100
ändert nicht die Helligkeit?
Zitat von: Mezzanine am 22 April 2020, 16:13:11
Hi SouzA,
die Lampe ist bereits eingeschaltet.
Aber trotzdem funktioniert das dimmen nicht :-[
Ich nutze zuerst
set Treppenlicht on
Dadurch geht der LED-Strip schonmal an.
Aber ein
set Treppenlicht pct 100
ändert nicht die Helligkeit?
Aus der commandref kann ich nicht ersehen, dass der RGBW dimmen kann. Zumindest nicht mit pct.
For Shelly RGBW devices (model=shellyrgbw and mode=color)
set <name> on|off
switches device <channel> on or off
set <name> on-for-timer|off-for-timer <time>
switches device on or off for <time> seconds.
set <name> hsv <hue value 0..360>,<saturation value 0..1>,<brightness value 0..1>
comma separated list of hue, saturation and value to set the color
set <name> rgb <rrggbb>
6-digit hex string to set the color
set <name> rgbw <rrggbbww>
8-digit hex string to set the color and white value
set <name> white <integer>
number 0..255 to set the white valueIch denke, du musst mit hsv hantieren.
Bis denn
SouzA
Hi SouzA,
ich glaube du hast recht...
Habe zwar schon x-mal die ref durchgelesen, aber anscheinend hatte ich Tomaten auf den Augen...
hier steht ganz klar:
For Shelly dimmer devices model=shellydimmer or (model=shellyrgbw and mode=white)
Ich wollte dass hier aber color steht...
::)
Danke für den Hinweis.
Hallo Pah,
vielen Dank für die Entwicklung das Shelly Moduls, ich verwende es aktuell um ein Shelly RGBW2 anzusteuern, was auch bestens funktioniert.
Einen wünsch hatte ich allerdings noch:
Wenn der RGBW2 "aus" geschaltet ist (Status "off") und ich setze einen RGB Werte über "set <name> rgb" bleibt der Stripe dunkel, erst nach einem zusätzlichen "set <name> on" werden die LEDs angesteuert. Hier fände ich es hilfreich wenn im Modul eine Attribute (z.b. "automaticMode") eingebaut werden könnte, welches wenn aktiviert den "on" Befehl automatisch sendet, sobald ein Farbwerte vorgegeben wird und wenn alle Farbwerte auf 00 stehen automatisch ein "set off".
Somit würde sich die Ansteuerung nicht von den HUE Lampen unterscheiden --> ist die HUE Lampe aus und ich sende einen Farbwerte geht sie auch direkt an.
Hilfreich wäre diese Funktion z.b. bei der Nutzung von Alexa, da aktuell ein "Alexa schalte <AlexaName> auf grün" nicht funktioniert wenn der Shelly gerade aus ist.
Ließe sich zwar auch alles irgendwie außenherum programmieren, aber direkt im Modul fände ich das sinnvoller aufgehoben.
Würde mich freuen wenn du diese Funktion in das Modul aufnehmen würdest.
Beste Grüße
Schlimbo
Zitatfände ich das sinnvoller aufgehoben
Ich nicht, sorry.
LG
pah
Mach Dir doch ein cmdalias, damit kriegst du das in einen Befehl:
create new FHEM commands or replace internal ones.
define <name> cmdalias <cmd_to_be_replaced or new_cmd> [parameter] AS <existing_cmd>
@andies: danke für den Tipp, hab das mal so umgesetzt:
defmod ShellyPower cmdalias set LEDstripe_Bad rgb .* AS {\
my $name = $EVTPART0;;\
my $rgb = $EVTPART2;;\
fhem "set $name rgb $rgb";;\
fhem "set $name:FILTER=state!=on on" if ($rgb ne "000000");;\
fhem "set $name:FILTER=state!=off off" if ($rgb eq "000000")\
}
@pah:
Bei "set <name> rgbw" ist mir noch ein kleiner Fehler aufgefallen:
Der weiße Kanal wird auf den Wert von blau gesetzt:
}elsif( $cmd eq "rgbw" ){
my $red=hex(substr($value,0,2));
my $green=hex(substr($value,2,2));
my $blue=hex(substr($value,4,2));
my $white=hex(substr($value,4,2));
Beste Grüße
Schlimbo
OK, werde ich umgehend korrigieren.
LG
pah
Hi Pah,
du hattest heute früh ja eine Änderung eingecheckt, hier wurde das Problem aber noch nicht behoben.
Mir ist gerade auch noch ein Fehler im Slider von "set white" aufgefallen:
--- 36_Shelly_org.pm 2020-05-15 07:58:19.641836655 +0200
+++ 36_Shelly.pm 2020-05-15 13:09:15.000000000 +0200
@@ -93,7 +93,7 @@
"rgbw" => "A",
"hsv" => "H",
"rgb:colorpicker,HSV" => "R",
- "white:slider,0,1,100" => "W"
+ "white:slider,0,1,255" => "W"
);
my %shelly_models = (
@@ -726,7 +726,7 @@
my $red=hex(substr($value,0,2));
my $green=hex(substr($value,2,2));
my $blue=hex(substr($value,4,2));
- my $white=hex(substr($value,4,2));
+ my $white=hex(substr($value,6,2));
$cmd=sprintf("red=%d&green=%d&blue=%d&white=%d",$red,$green,$blue,$white);
Shelly_dim($hash,"color/0","?".$cmd);
}elsif( $cmd eq "white" ){
Gruß Schlimbo
Hallo pah,
Als Gegenstück zu "set rgbw" würde ich mir noch ein Reading "rgbw" wünschen, dies wäre bei der Verwendung von FILTER sehr nützlich:
set LEDstripe_Bad:FILTER=rgbw!=00FF0000 rgbw 00FF0000
Spricht da etwas dagegen?
Gruß
Schlimbo
Gefixt hatte ich das schon - nur, weil zwischen Tür und Angel, die falsche Version eingecheckt...
LG
pah
Danke für den fix, könntest du den Slider bitte auch noch korrigieren?
Zitat von: Schlimbo am 15 Mai 2020, 13:18:22
Mir ist gerade auch noch ein Fehler im Slider von "set white" aufgefallen:
Gruß Schlimbo
Hallo pah,
ich habe gerade einen kleinen Schönheitsfehler gefunden. Meine Oberfläche ist auf deutsch eingestellt. Wenn ich nun den Link "Device specific help" anklicke, dann kommt der Hinweis "Absichtlich keine deutsche Dokumentation vorhanden, die englische Version gibt es hier: Shelly". Soweit so gut. Klicke ich nun aber auf den Link "Shelly", dann zeigt der Link auf die lokale Adresse http://{lokaleIP}:{lokalerPort}/commandref.html#Shelly . Klicke ich diesen an, dann komme ich auf die lokale Fhem-Startseite. Ich denke der Link müsste https://fhem.de/commandref.html#Shelly lauten. Oder?
Grüße, Cluni
...man kann FHEM auf deutsch einstellen ?
Hallo miteinander,
ich hab einen shelly rgbw2 und versuche gerade vergeblich per action und out_on die Statusänderungen ins fhem zu bringen, kriege es aber nicht hin. Weder mit zusätzlicher Kanalangabe noch ohne. Mit einem shelly 1 und einem shellyPlugS klappt es, wie man es auch der commandref erwartet.
Ich hab auch schon versucht in den Code zu schauen und im github gesehen, dass am 27.11.2019 Support für dimmer eingebaut wurde. Meine Perlkenntnisse sind aber nicht gut genug um einfach rauszulesen, ob das für den rgbw auch geht. (Mit model=shellydimmer hab ich es auch probiert, da geht nur der button und out_on macht keine Reaktion).
Mach ich irgendwas falsch oder ist das evtl. nur nicht implementiert.
Danke schonmal!
Ich verstehe die Frage nicht.
LG
pah
Ich versuche im shelly-Webinterface im Action-Feld für ein und aus sowas:
http://raspberrypi:8083/fhem?XHR=1&cmd=set%20shelly_WZ_Ledband%20out_on%201
einzutragen, damit der Status im fhem direkt aktualisiert wird wird, wenn ich auf den Lichtschalter drücke und nicht erst nach Ablauf des Polling-Intervals.
Beim shelly1 und ShellyPlugS klappt es, beim rgbw2 nicht. Es gibt einfach im fhem-device keinerlei Reaktion.
Auch button_on/button_of macht im rgbw2 device nichts. Bei den anderen beiden wird dann ein reading button angelegt, das entsprechend auf on oder off geht.
Diese "Action"-Funktionalität wurde beim RGBW2 erst vor kurzer Zeit in die Firmware eingebaut und ist noch nicht im Modul. Kommt frühestens in 2 Wochen rein.
Workaround: Dem Device ein userReading "buttonX" geben und beim Aufruf der REST-Schnittstelle (über das "Action"-Feld im Shelly) nicht "set ..." sondern "setreading <device> buttonX"
Achtung: NICHT "button" verwenden - das würde vom Modul beim Setzen eines anderen Attributes gelöscht.
LG
pah
Zitat von: cs-online am 18 Juni 2020, 12:22:30
...man kann FHEM auf deutsch einstellen ?
Device ,,global", Attribut ,,language" auf ,,DE"
Zitat von: det. am 13 April 2020, 12:14:47
Hallo Peter,
habe seit längerer Zeit bei jedem Neustart folgende Meldung im LOG:
2020.04.13 10:24:14 1: Including ./log/fhem.save
2020.04.13 10:24:14 1: [Shelly_Attr] setting the mode attribute only works for model=shelly2|shelly2.5|shellyrgbw
2020.04.13 10:24:14 1: [Shelly_Attr] setting the mode attribute only works for model=shelly2|shelly2.5|shellyrgbw
2020.04.13 10:24:14 1: [Shelly_Attr] setting the mode attribute only works for model=shelly2|shelly2.5|shellyrgbw
2020.04.13 10:24:14 1: [Shelly_Attr] setting the mode attribute only works for model=shelly2|shelly2.5|shellyrgbw
Da Du in einem anderen Beitrag heute eine kleine Überarbeitung des Shelly Modul angekündigt hast, möchte ich noch mal auf die unzutreffende Meldung im Log hinweisen. Auch wenn das genau bei Dir nicht vorkommt, muss es doch eine Ursache haben.
Vielen Dank,
List eines der Devices?
LG
pah
exemplarisch eines davon (seit ich vorgestern noch einen shelly 2.5 als Rollodevice dazubekommen habe, ist noch eine solche Meldung mehr):
Internals:
.AttrList
.FhemMetaInternals 1
DEF 192.168.2.247
DURATION 0
FUUID 5cf3cf38-f33f-f5da-26a5-a5fbf6a5db16b7cd
FVERSION 36_Shelly.pm:v2.13.0-s21949/2020-05-16
INTERVAL 60
NAME TVBacklight
NR 500
STATE on
TCPIP 192.168.2.247
TYPE Shelly
.attraggr:
.attreocr:
rgb
firmware
.attrminint:
READINGS:
2020-06-16 22:38:37 L-blue 255
2020-06-16 22:39:32 L-green 11
2020-06-16 22:39:32 L-red 252
2020-06-16 22:38:37 L-white 0
2019-06-02 15:34:45 cloud disabled
2019-08-10 13:06:29 config effect=0 [channel 0]
2020-06-19 21:25:06 energy 1.5
2020-06-16 22:38:37 firmware v1.7.2
2020-06-19 21:13:06 network <html>connected to <a href="http://192.168.2.247">192.168.2.247</a></html>
2020-06-19 21:23:05 overpower 0
2020-06-18 21:01:02 power 7.9
2020-06-16 22:39:32 rgb FC0BFF
2020-06-19 21:13:06 state on
Attributes:
alexaName Fernsehlicht
devStateIcon {if (ReadingsVal( $name, 'state', 'undef' ) =~ m/[a-z]/ ) { return 'Error:light_light_dim_00@black on:light_light_dim_100'}}
event-on-change-reading rgb,firmware
group Bedienelemente
mode color
model shellyrgbw
room Wohnzimmer
verbose 0
webCmd rgb:rgb FFFFFF:rgb ff0000:rgb 98FF23:rgb 0000ff
widgetOverride rgb:colorpicker,RGBWRAW:
defmod TVBacklight Shelly 192.168.2.247
attr TVBacklight alexaName Fernsehlicht
attr TVBacklight devStateIcon {if (ReadingsVal( $name, 'state', 'undef' ) =~ m/[a-z]/ ) { return 'Error:light_light_dim_00@black on:light_light_dim_100'}}
attr TVBacklight event-on-change-reading rgb,firmware
attr TVBacklight group Bedienelemente
attr TVBacklight mode color
attr TVBacklight model shellyrgbw
attr TVBacklight room Wohnzimmer
attr TVBacklight verbose 0
attr TVBacklight webCmd rgb:rgb FFFFFF:rgb ff0000:rgb 98FF23:rgb 0000ff
attr TVBacklight widgetOverride rgb:colorpicker,RGBW
Hey Leute
ich habe hier extra alles noch mal nachgelesen, aber entweder habe ich es übersehen oder es wurde noch nicht gefragt, und zwar würde ich gerne wissen ob das "Shelly Door Window 2" von Fhem unterstützt wird? Sie wären super da sie Wlan nutzen oder hat einer von euch ein anderes Produkt was mit Wlan funktioniert und was er mir empfehlen könnte?
Caleus
Zitat von: Cluni am 19 Juni 2020, 06:24:51
Device ,,global", Attribut ,,language" auf ,,DE"
Ähm, hab ich gemacht, dann shutdown restart, alles sieht genauso aus, wie vorher, alles auf englisch... Wo ist jetzt der Mehrwert ?
Hallo @all,
Eigentlich eine Anfängerfrage, gehört aber hier zum Shelly Modul - wie habt Ihr beim Shelly 2.5 in der Betriebsart Rollo die Aussperren Blockierung bei geöffneter Terrassentür gelöst?
Hatte vorher da ein z-Wave Device, da ging das mit set <$$$> disable wenn Türgriff nicht zu.
Das kann https://wiki.fhem.de/wiki/AutoShuttersControl handeln.
Zitat von: amenomade am 21 Juni 2020, 00:14:28
Das kann https://wiki.fhem.de/wiki/AutoShuttersControl (https://wiki.fhem.de/wiki/AutoShuttersControl) handeln.
Danke, so habe ich das auch gelöst und es hat gestern Nacht funktioniert. Nur vertraue ich dem ASC von cooltux solange es noch in Entwicklung ist in der Sache nicht zu 100% und bevorzuge eine zusätzliche Blockierung des Hardware Rollo Device - diesen Befehl für Shelly 2.5 suche ich.
MMn kannst du ASC dafür trauen. ASC wird immer komplexer da Marko immer noch weitere Funktionalitäten einbaut, und die Abhängigkeiten zwischen den Funktionen und Zustände natürlich wächst. Wie es aussieht, wird es immer in Entwicklung sein ;)
Aber für grundlegende Funktionalitäten wie "Sperre wenn Tür offen" funktioniert es wie ein Zauber.
Ich mache damit Beschattung, Belüftung wenn Fenster gekippt, Astro Steuerung mit Zeitgrenzen, und Sperre bei offenem Ding, also auch grundsätzliche Funktionen und habe nie ein Problem gehabt
Ist auch eine Steuerung der LED-Birnen und ein Auslesen der Tür- bzw Temperatur/Hygrometer- Wasser-Sensoren etc., die es von Shelly gibt, möglich?
Danke
Chipmunk
ZitatWie es aussieht, wird es immer in Entwicklung sein
Kann sein. Ich habe ASC zwar in dem FHEM-Buch gut beworben, mir ist es aber inzwischen für meine Zwecke zu komplex.
Darum habe ich für das Blockieren von Rollläden bei offener Tür inzwischen sehr schlanke eigene Routinen, die ich demnächst mal in ein Modul gießen werde.
@chipmunk: Die Leuchten sollten prinzipiell einfach integrierbar sein, ich werde mir sie aber nicht kaufen, nur um das durchzuziehen. Für die Sensoren ist die Integration nicht sinnvoll, da sie ja nicht gesteuert werden können. In dem Fall rate ich zu MQTT.
@det.: Bin den Meldungen auf der Spur, dauert aber noch.
@Caleus: Die Anrede "Hey" schätze ich nicht so.
LG
pah
Lieber Prof. Dr. Peter Henning
Ich entschuldige mich, ich hatte nicht vor unangemessen zu klingen, ich entnehme deiner Aussage, das die Shelly Door Sensoren, nur per MQTT mit FHME nutzbar sind?
Gruß Caleus
So förmlich muss es nun auch wieder nicht sein.
Derzeit: Ja.
Noch ein Tipp von mir: Die WLAN-Interfaces fressen, wenn sie aktiv sind, eine Menge Energie. Infolgedessen sind batteriebetriebene WLAN-Sensoren immer heikel. Aus diesem Grund vertreibt Allterco Robotics ja auch USB-Stromversorgungen für den HT-Sensor.
Ich würde deshalb an einer Tür (insbesondere, wenn sie häufig benutzt wird) eher zu anderen Systemen raten.
LG
pah
Ok, ich wollte nur meine Entschuldigung zum Ausdruck bringen,
Naja ok also ich suche halt was für meine Fenster, zur zeit habe ich 433 MHZ Stick sowie Bluetooth und Wlan zur Verfügung eventuell kannst du mir ja etwas für meine Fenster empfehlen aus diesen Bereichen.
MfG Caleus
Tipps kann ich nur eingeschränkt geben, weil ich selbst andere Systeme nutze - aber Sonoff-Türkontakte 433 MHz sind spottbillig, weniger als 5€. Müsste man in dem entsprechenden Subforum diskutieren.
LG
pah
Hallo Pah
Seit einiger Zeit nutze ich Dein Modul und bin sehr zufrieden. Danke dafür!
Einen kleinen Wunsch hätte ich jedoch noch.
Die Shellys geben die Temperatur und rssi Werte aus ist es möglich die ebenfalls als Reading zu erfassen?
Gruß
Daniel
Ich habe mir heute in FHEM ein Shelly2.5 Modul eingerichtet. Dabei ist mir aufgefallen, dass die reading relay_0 und relay_1 nach einem set on 0|1 nicht aktualisiert werden.
Erst ein neu laden der gesamten Seite mittels F5 oder neu öffnen vie menü führt ein korrektes update aus.
Ist das ein Fehler im Modul oder habe ich eventuell etwas falsch konfiguriert?
ZitatDie Shellys geben die Temperatur und rssi Werte aus ist es möglich die ebenfalls als Reading zu erfassen?
Ich setze es mal auf die Wunschliste und werde darüber nachdenken. RSSI eher weniger - der sollte sich ja nicht ändern, den kann man einmal in der Weboberfläche ansehen. Temperatur ist aber ggf. ein sinnvoller Messwert.
Allerdings hat die (Innen-)Temperatur des Shelly mit der Raumtermperatur nichts zu tun, darüber solte man sich im Klaren sein.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 01 Juli 2020, 04:02:24
Ich setze es mal auf die Wunschliste und werde darüber nachdenken.
Danke dafür!
Zitat von: Prof. Dr. Peter Henning am 01 Juli 2020, 04:02:24
RSSI eher weniger - der sollte sich ja nicht ändern, den kann man einmal in der Weboberfläche ansehen. Temperatur ist aber ggf. ein sinnvoller Messwert.
Hintergruind hierfür ist die Möglichkeit zur Fehlerfindung. Das Problem ist das Shellys allgemein empfangstechnisch etwas schwach sind und anfällig für Störfelder.
Ich hatte aktuell das Problem das ein Shelly immer mal wieder nicht geschaltet hat da er aus dem WLAN geflogen ist. Zunächst hatte ich gedacht das es ein Temperaturproblem ist bis ich festgestellt habe das der rssi Wert sporadisch unabhängig von der Temperatur stark eingebrochen ist und ich auf Ursachenforschung gegangen bin. Für solche Situationen ist es durchaus sinnvoll den rssi Wert beobachten zu können.
Ich würde mich wirklich sehr über Deine Zustimmung freuen.
Gruß
Daniel
Zitat von: Prof. Dr. Peter Henning am 01 Juli 2020, 04:02:24
Allerdings hat die (Innen-)Temperatur des Shelly mit der Raumtermperatur nichts zu tun, darüber solte man sich im Klaren sein.
Natürlich weicht die Innentemperatur unter Umständen stark von der Raumtemperatur ab. Das macht den Wert ja gerade interessant.
Zitat von: WhyTea am 01 Juli 2020, 16:16:51
Danke dafür!Hintergruind hierfür ist die Möglichkeit zur Fehlerfindung. Das Problem ist das Shellys allgemein empfangstechnisch etwas schwach sind und anfällig für Störfelder.
Ich hatte aktuell das Problem das ein Shelly immer mal wieder nicht geschaltet hat da er aus dem WLAN geflogen ist. Zunächst hatte ich gedacht das es ein Temperaturproblem ist bis ich festgestellt habe das der rssi Wert sporadisch unabhängig von der Temperatur stark eingebrochen ist und ich auf Ursachenforschung gegangen bin. Für solche Situationen ist es durchaus sinnvoll den rssi Wert beobachten zu können.
Hast du ne Fritzbox?
Da kannst du sowas mit dem FritzBox-Modul dann auch beobachten...
bis denn
SouzA
Hallo Pah,
mal wieder eine Frage zu deinem Modul.
Ich verwende noch einen Shelly 2, der liefert leider keine getrennten Leistungsdaten für die beiden Kanäle.
Ich habe aber feste Lasten (Licht) deren Wert ich ermittelt habe indem ich nur jeweils einen Kanal eingeschaltet habe.
Jetzt würde ich gerne energy und power selbst in den nach Kanal getrennten Devices eintragen, damit ich es wie alle anderen Shellies behandeln kann (Verbrauch,Energiekosten).
Ist es nicht möglich ein Attribut für den Typ shelly 2 hinzuzufügen das die automatische Erzeugung der readings power und energy abschaltet, damit meine für beide devices (Kanal1,Kanal2) getrennt berechneten Werte nicht von dem einen gemeinsamen des Shelly 2 überschrieben wird.
Wenn ich dafür eigene andere Userreadings einführe brauche ich für alle Folgeschritte eine Sonderbehandlung bei Shelly 2 Devices.
Hoffe auf eine positive Antwort auch wenn keine Shelly 2 mehr verkauft werden.
LG Bombardi
Der Shelly 2 hat nur eine Leistungsmessung. Dafür müsstest du den Shelly 2.5 haben (glaube der hat zwei einzelne Kanäle)...
Ich werde keine Sonderlösung dieser Art einbauen.
LG
pah
Irgendwie verstehe ich Dein Ansinnen nicht.
Wozu soll das gut sein, wenn Du für z.B. power zur Aufteilung zwei Readings mit unterschiedlichen Namen erstellen musst?
Dann können diese doch durch das Standardreading gar nicht überschrieben werden.
Der Shelly 2.5 liefert energy_0 und energy_1 bzw. power_0 und power_1.
Daraus kann ich ein userreading energy bzw. power erzeugen für jedes Device einzeln, jenachdem welchen Kanal ich nutze
Shelly PlugS, Shellyrgbw liefern direkt power und energy, da er sie messen können.
Ich möchte beim Shelly 2 nur das selbe wie beim 2.5 erreichen, auch wenn der Shelly 2 nicht getrennt messen kann.
Die jetzige implementierung verhindert leider, das ich power und energy als userreading getrennt pro Device erzeugen kann, weil es vom Modul überschrieben wird für beide devices.
Der Vorschlag mit einem zusätzlichen Attribut wäre um abwärtskompatibel zu sein.
Das ist imho Unfug.
Der Shelly 2 liefert von Haus aus nur einen Messwert für power und energy jeweils in Summe für beide Kanäle. Das hat nichts mit dem Modul zu tun.
Wenn Du es aufteilen willst, musst Du bei bekannter Last je Kanal die Leistung über die Zeit integrieren (in Deinem Fall also einfach Leistung * Zeit) um auf den Energieverbrauch zu kommen. Oder aber Einschaltdauer des jeweiligen Kanals mal zugehöriger Leistung (da konstant nach Deinen Aussagen verändert sich auch power je Kanal nicht).
Daher kannst Du die vorhandenen Readings für power und energy so zu sagen für die weitere Betrachtung vergessen.
Ich verstehe schon, was er möchte. Allerdings verstehe ich nicht, was gegen separate userreadings spricht, die einen anderen Namen tragen.
Das Modul wird jedenfalls nicht geändert, weil ich damit ziemlich tief an der inneren Struktur herumpfuschen müsste.
LG
pah
Ich möchte weiter wie für alle anderen Shellys das statistics Modul verwenden um meine Verbrauchsstatistik zu führen.
Dieses verwendet dazu aber das Reading Energy, somit kann ich kein anderes verwenden.
Du kannst dem statistics Modul sagen, welche Readings es verwenden soll. Siehe commandref.
Hallo,
erst mal ein Dankeschön für eure Arbeit.
Ich liebe die Shelly's und mit dem Modul sind sie so schön einfach anzusprechen.
Nun meine Frage:
Wird das Modul mit dem I3 ergänzt?
Ich möchte mir ihm meine Rollläden schalten und bin schon ganz heiß darauf.
Hallo,
auch von mir zunächst ein dickes Dankeschön für die tolle Arbeit!
Wird das Modul auch um den Button 1 ergänzt?
Danke und Gruß,
Kurt
Hallo
Aufgrund von umabiarbeiten ist aktuell ein Shelly ohne Strom bei mir.
Dadurch wird leider mein Logfiles voll geschrieben.
2020.07.21 21:40:27 1: [Shelly_status] has error 192.168.6.149: Keine Route zum Zielrechner (113)
2020.07.21 21:41:31 1: [Shelly_status] has error 192.168.6.149: Keine Route zum Zielrechner (113)
2020.07.21 21:42:34 1: [Shelly_status] has error 192.168.6.149: Keine Route zum Zielrechner (113)
2020.07.21 21:43:37 1: [Shelly_status] has error 192.168.6.149: Keine Route zum Zielrechner (113)
2020.07.21 21:44:40 1: [Shelly_status] has error 192.168.6.149: Keine Route zum Zielrechner (113)
2020.07.21 21:45:43 1: [Shelly_status] has error 192.168.6.149: Keine Route zum Zielrechner (113)
2020.07.21 21:46:46 1: [Shelly_status] has error 192.168.6.149: Keine Route zum Zielrechner (113)
2020.07.21 21:47:49 1: [Shelly_status] has error 192.168.6.149: Keine Route zum Zielrechner (113)
2020.07.21 21:48:52 1: [Shelly_status] has error 192.168.6.149: Keine Route zum Zielrechner (113)
2020.07.21 21:49:55 1: [Shelly_status] has error 192.168.6.149: Keine Route zum Zielrechner (113)
2020.07.21 21:50:58 1: [Shelly_status] has error 192.168.6.149: Keine Route zum Zielrechner (113)
Gibt es einne Möglichkeit das Device vorrübergehen zu deaktivieren?
Gruß
Daniel
mit attr <shellyname> interval 0 ?
Zitat von: CommandRef<interval>
Update interval for reading in seconds. The default is 60 seconds, a value of 0 disables the automatic update.
Ich habe sowohl den I3, als auch einen Button hier liegen. Den Button habe ich schon voll in Betrieb - geht ganz einfach mit einem Dummy
Zitat
define WB.SB dummy
Attributes:
group remote
room Kontrollraum
setList short:noArg long:noArg double:noArg triple:noArg
und einem DOIF
ZitatInternals:
define WZ.AB.N DOIF
([WZ.SB:"short"])
({fhem194Cmd("set Tab1.EG activateVoiceInput")})
DOELSEIF
([WZ.SB:"double"])
({fhem194Cmd("set Tab2.EG activateVoiceInput")})
DOELSEIF
([WZ.SB:"triple"])
({fhem194Cmd("set Tab.M activateVoiceInput")})
Attributes:
do always
Die set-Kommandos für den Dummy werden einmalig in das Webfrontend des Buttons eingetragen, das wars dann. Also warum sollte man dafür noch das Modul umbauen? Könnte natürlich sein, dass das Ding auch seinen Batteriezustand kennt - wenn ja, wäre der Einbau ins Modul sinnvoll.
Beim I3 muss ich mir auch noch das API genauer ansehen.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 22 Juli 2020, 05:35:08
Ich habe sowohl den I3, als auch einen Button hier liegen. Den Button habe ich schon voll in Betrieb - geht ganz einfach mit einem Dummyund einem DOIF
Die set-Kommandos für den Dummy werden einmalig in das Webfrontend des Buttons eingetragen, das wars dann. Also warum sollte man dafür noch das Modul umbauen? Könnte natürlich sein, dass das Ding auch seinen Batteriezustand kennt - wenn ja, wäre der Einbau ins Modul sinnvoll.
Hallo,
danke!
Anfängerfrage: Wie bringe ich denn jetzt den Dummy mit der ip-Adresse des physischen Schalters zusammen?
Danke und Gruß,
Kurt
Gar nicht. Im physischen Schalter sind lediglich die REST-Aufrufe für FHEM gespeichert. Wie diese aussehen, ist an ganz vielen Stellen dokumentiert - auch in der ComandRef des Shelly-Moduls.
LG
pah
Hallo,
Ich habe seit geraumer Zeit (schon mit modul version 2.11) Warnings beim Ansprechen meiner Shelly 1 devices (Firmware erst kürzlich aktualisiert):
2020.07.26 12:15:00 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4796.
2020.07.26 12:15:00 1: stacktrace:
2020.07.26 12:15:00 1: main::__ANON__ called by fhem.pl (4796)
2020.07.26 12:15:00 1: main::readingsBulkUpdateIfChanged called by ./FHEM/36_Shelly.pm (925)
2020.07.26 12:15:00 1: main::Shelly_status called by ./FHEM/36_Shelly.pm (879)
2020.07.26 12:15:00 1: main::__ANON__ called by FHEM/HttpUtils.pm (634)
2020.07.26 12:15:00 1: main::__ANON__ called by fhem.pl (759)
Scheint davon zu kommen, dass der Parameter "overpower" abgefragt wird, der aber von meinem Shelly nicht gemeldet wird.
Die Abfrage von /settings/relay/0 ergibt:
{"name":null,"ison":false,"has_timer":false,"default_state":"off","btn_type":"toggle","btn_reverse":1,"auto_on":0.00,"auto_off":0.00,"power":0.00,"btn_on_url":null,"btn_off_url":null,"out_on_url":null,"out_off_url":null,"longpush_url":null,"shortpush_url":null,"schedule":false,"schedule_rules":[]}
Wird dieser Parameter eventuell nur gesetzt, wenn man einen max_power gesetzt hat?
Meine Devices laufen bis auf die nötigsten Settings im Auslieferungszustand (nur über die Weboberfläche konfiguriert).
Ich kommentiere immer die Zeile aus, die das Warning erzeugt (benutze den Parameter ja nicht), aber das ist ja keine Dauerlösung
#readingsBulkUpdateIfChanged($hash,"overpower".$subs,$overpower);
Mache ich irgendwas falsch oder wenn dies ein normales Verhalten der Shelly-1 ist, könnte man einen Test einbauen ob der Parameter leer ist? Ich bin ein Fan von Logfiles ohne Warnings :)
Danke,
Jörg
Hallo allerseits, habe #537 und folgende gelesen und verstanden.
Ich möchte dennoch höflichst beantragen, dass dieser Sensor aufgenommen wird, weil er kann
Open / Close
Temperatur in C und F
Neigung in °
Vibration
Licht / helligkeit
Batteriestatus in %
Ich selbst betreibe das Teil provisorisch (aus oben genannten Gründen) mit einen lokalen 5V= Netzteil.
Er mault zwar wegen etwas Unterspannung, aber es geht gut.
Es geht übrigens auch mit einer Lithium 18650 Zelle (ca. 50% Batterie).
Der UserGuide ist (noch) nicht downloadbar, darum hier anhängend für Interessenten.
Hallo,
ich komme mit dem i3 einfach nicht zum Ziel. Wahrscheinlich nur ein üblicher DummUserFehler.
Nachdem ich das hier gelesen habe, dachte ich mir das müsste mit dem i3 doch auch gehen.
Einfach die REST aufrufe eintragen.
Zitat von: Prof. Dr. Peter Henning am 22 Juli 2020, 05:35:08
Ich habe sowohl den I3, als auch einen Button hier liegen. Den Button habe ich schon voll in Betrieb - geht ganz einfach mit einem Dummyund einem DOIF
Die set-Kommandos für den Dummy werden einmalig in das Webfrontend des Buttons eingetragen, das wars dann. Also warum sollte man dafür noch das Modul umbauen? Könnte natürlich sein, dass das Ding auch seinen Batteriezustand kennt - wenn ja, wäre der Einbau ins Modul sinnvoll.
Leider werden die Aktionen nicht ausgeführt. Wenn ich die URL in einen Browser eingebe, werden sie ausgeführt.
Ich möchte mit dem Shelly i3 Rollläden über fhem steuern.
short -> runter
double -> rauf
long -> stop
trible -> 50%
Dies wäre eine Beispiel-URL. Diese habe bei "Button short pressed url" eingetragen.
http://user:password@rasp-fhem:8083/fhem?XHR=1&cmd=set%20EG_Wohnzimmer_Tuer.Si3_1%20short%20[1]&fwcsrf=meinTokenHat mir jemand eine Idee?
Warum habe ich wohl statt eines " " dort stehen %20 ? ==> Sonderzeichen ersetzen !
https://de.wikipedia.org/wiki/URL-Encoding
LG
pah
Hallo,
velen Dank für den Hinweis mit den Sonderzeichen. Allerdings hatte ich die " " schon durch &20 ersetzt, wie in meiner URL zu sehen ist.
http://user:password@rasp-fhem:8083/fhem?XHR=1&cmd=set%20EG_Wohnzimmer_Tuer%2ESi3_1%20long%20%5B1%5D&fwcsrf=meinToken
Was ich übersehen hatte, waren die "[]"und den ".".
Diese habe ich nun auch entsprechend kodiert. Leider wird die URL vom Shelly immer noch nicht aufgerufen.
Wenn ich mit dem Browser oder Postman sende, funktioniert sie. Das verstehe ich nicht.
LG
Klaus
Zitat von: seppi9899 am 06 August 2020, 19:09:30
Leider wird die URL vom Shelly immer noch nicht aufgerufen.
Wenn ich mit dem Browser oder Postman sende, funktioniert sie. Das verstehe ich nicht.
Nämliches technische Problem habe ich auch genau so mit dem Action-http-Aufruf.
via Browser = Ja, via Shelly = Nein
http://raspb:8083/fhem?cmd=set%20Y_LED%20off&XHR=1Ich bin auch irritiert
Habt ihr beide den NAMEN oder die IP, also:
seppi9899: rasp-fhem
Ralph: raspb
oder die IP-Adresse!?
Wenn Name: kann der Shelly den evtl. nicht "auflösen"...
Gruß, Joachim
Habs auch mit der IP probiert, klar doch. Nitschewo
Man sollte wissen, ob der Shelly das überhaupt schickt ?
Ja, es gibt Sniffer. Und zu denen bin ich zu blöd und zu alt.
@Ralph: hast du einen csrfToken gesetzt!?
Wenn nein: keine gute Idee!
Wenn ja: hast du den angehängt!?
EDIT: bzw. deaktiviert!? Weil Standard ist ja: es gibt einen...
EDIT: sollte aber etwas im fhem Log stehen... Bzw.: überhaupt schon mal "dort" geschaut!!?
EDIT: hat aber ja jetzt nix (mehr) mit dem Modul zu tun!!?
Gruß, Joachim
@ Prof. Dr. Peter Henning und MadMax-FHEM
Vielen Dank für eure Hilfe.
Name durch IP ersetzt, jetzt geht es. :)
LG Klaus
Danke an Max-FHEM *hofknicks*
EDIT: bzw. deaktiviert!? Weil Standard ist ja: es gibt einen... Ja, scheibenkleister, asche über mein Haupt
EDIT: sollte aber etwas im fhem Log stehen... Bzw.: überhaupt schon mal "dort" geschaut!!? Ja, war nix
EDIT: hat aber ja jetzt nix (mehr) mit dem Modul zu tun!!? Wo Du Recht hast, aber ich war halt im Strag drin, So Sorry
@Ralf: heißt es geht jetzt!?
Gruß, Joachim
Ernst gemeinter Tipp: Devicenamen wie EG_Wohnzimmer_Tuer.Si3_1 sollte man vermeiden - das ist zwar schön systematisch, aber fehleranfällig.
Zweiter Tipp: Die Shellys sollten richtig konfiguriert werden, auch bezüglich des DNS-Eintrages - dann ergibt sich das hier aufgetretene Problem gar nicht.
LG
pah
Ganz blöde Frage, kann ich irgendwie erkennen beziehungsweise auswerten ob die Lampe an einem Shelly 1 über die App beziehungsweise WLAN ausgelöst wurde oder über den Switch (SW) Eingang?
Wenn man den Switch-Eingang mit einer REST-Message an FHEM melden lässt, dass der Button gedrückt wurde: sicher.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 07 August 2020, 05:12:14
Ernst gemeinter Tipp: Devicenamen wie EG_Wohnzimmer_Tuer.Si3_1 sollte man vermeiden - das ist zwar schön systematisch, aber fehleranfällig.
Was konkret ist denn an demDevicenamen fehleranfällig?
Was wäre ein besserer Name?
Hallo zusammen, ich weiss nicht ob das hier so der richtige Rahmen für meine Frage ist, aber ich versuche es trotzdem einfach mal.
Also ich habe das Modul eingerichtet und es funktioniert soweit auch gut mit dem Rgbw 2 Controller. Mein Ziel ist es über den Controller
4 gleichfarbige Stripes über die 4 Kanäle des Controllers seperat zu dimmen. Ich habe hierzu das Module auf Mode:white umgestellt. Nun sehe ich
unten in den Readings 4 pct Kanäle und hatte gehofft jeden einzelnen mit einem set pct Befehl auf den gewünschten Helligkeitswert einstellen
zu können. Leider weiss ich nicht ob dies überhaupt machbar ist, bezw. wie der set pct Befehl aussehen muss um den gewünschten Wert dem jeweiligen
Kanal zuzuweisen. Ich hoffe die Augen rollen nun nicht gleich in richtung Deckenlampe aber trotz des vielen Lesens ist doch alles Anfang schwer. LG Timmy
Zitat von: timmy2000 am 25 August 2020, 19:37:46
Hallo zusammen, ich weiss nicht ob das hier so der richtige Rahmen für meine Frage ist, aber ich versuche es trotzdem einfach mal.
Also ich habe das Modul eingerichtet und es funktioniert soweit auch gut mit dem Rgbw 2 Controller. Mein Ziel ist es über den Controller
4 gleichfarbige Stripes über die 4 Kanäle des Controllers seperat zu dimmen. Ich habe hierzu das Module auf Mode:white umgestellt. Nun sehe ich
unten in den Readings 4 pct Kanäle und hatte gehofft jeden einzelnen mit einem set pct Befehl auf den gewünschten Helligkeitswert einstellen
zu können. Leider weiss ich nicht ob dies überhaupt machbar ist, bezw. wie der set pct Befehl aussehen muss um den gewünschten Wert dem jeweiligen
Kanal zuzuweisen. Ich hoffe die Augen rollen nun nicht gleich in richtung Deckenlampe aber trotz des vielen Lesens ist doch alles Anfang schwer. LG Timmy
Moin,
du musst zwei Befehle absetzen:
set Beleuchtung on
set Beleuchtung pct 30Wenn ich deine Frage richtig verstanden habe, müsste das dein Problem beheben, oder?
Damit hatte ich zum Anfang auch Probleme ;)
Bis denn
SouzA
Danke schon mal für die freundliche Hilfestellung ! Das bringt mich leider auch nicht wirklich weiter, da ich hier auch wieder darauf verwiesen werde, den Channel
mit anzugeben . Es folgt auf den set Befehl "wrong channel given and defchannel attribute not set properly" Danke trotzdem für den Hinweis auf den set on Befehl.
Zitat von: timmy2000 am 26 August 2020, 19:23:49
Danke schon mal für die freundliche Hilfestellung ! Das bringt mich leider auch nicht wirklich weiter, da ich hier auch wieder darauf verwiesen werde, den Channel
mit anzugeben . Es folgt auf den set Befehl "wrong channel given and defchannel attribute not set properly" Danke trotzdem für den Hinweis auf den set on Befehl.
Sorry,
da kann ich dann auch nicht helfen.
Ich hab nur den normalen Dimmer. Da gibt es keine channel...
Bis denn
SouzA
Zitat von: timmy2000 am 26 August 2020, 19:23:49
Danke schon mal für die freundliche Hilfestellung ! Das bringt mich leider auch nicht wirklich weiter, da ich hier auch wieder darauf verwiesen werde, den Channel
mit anzugeben . Es folgt auf den set Befehl "wrong channel given and defchannel attribute not set properly" Danke trotzdem für den Hinweis auf den set on Befehl.
Mach ein "set <name> xtrachannels", dann hast Du ein Device (readingsProxy) pro Channel, und die kannst nw dann ohne Channelnummer im Befehl steuern.
Danke ich habe es hin bekommen. Habe mehrere Geräte mit verschiedenen defchannel angelegt .. Danke vielmals für die Hilfe
Hallo zusammen,
Ich habe gestern seit langem mal wieder ein firmware update gemacht 1.6 -> 1.8
Seitdem sind alle meine Shelly's (1, 2, 2.5) offline.
Wenn ich sie neu definiere bekomme ich eine Verbindung welche nach kurzer zeit dann verloren geht.
Hat sich da was geändert was ich in them anpassen muss? Meine define ist wie folgt:
Internals:
DEF 192.168.188.104
DURATION 0
FUUID 5dfc8fa4-f33f-aa80-1046-c81a7cdd9ad4dea5
INTERVAL 60
NAME EG_GangLicht
NR 124
STATE Error
TCPIP 192.168.188.104
TYPE Shelly
READINGS:
2019-12-20 10:08:52 cloud disabled
2020-08-26 08:42:28 firmware v1.8.0
2020-08-27 08:40:44 network not connected
2020-08-27 08:39:39 relay off
2020-08-27 08:40:44 state Error
Attributes:
icon light_downlight
model shelly1
room Haus
Im log sehe ich folgendes
2020-08-27 08:43:30 Shelly SZ_SchrankLicht Error
2020-08-27 08:43:30 Shelly SZ_SchrankLicht network: not connected
2020-08-27 08:43:43 Shelly WK_Rollo Error
2020-08-27 08:43:43 Shelly WK_Rollo network: not connected
2020-08-27 08:46:59 Shelly EG_GangLicht network: <html>connected to <a href="http://192.168.188.104">192.168.188.104</a></html>
2020-08-27 08:46:59 Shelly EG_GangLicht off
Ist mit dem shelly rgbw2 ein slow dim up/down realisierbar ? Hat jemand Erfahrungen damit ?
Zitat von: ulli am 27 August 2020, 08:41:17
Hallo zusammen,
Ich habe gestern seit langem mal wieder ein firmware update gemacht 1.6 -> 1.8
Seitdem sind alle meine Shelly's (1, 2, 2.5) offline.
Wenn ich sie neu definiere bekomme ich eine Verbindung welche nach kurzer zeit dann verloren geht.
Hat sich da was geändert was ich in them anpassen muss? Meine define ist wie folgt:
Internals:
DEF 192.168.188.104
DURATION 0
FUUID 5dfc8fa4-f33f-aa80-1046-c81a7cdd9ad4dea5
INTERVAL 60
NAME EG_GangLicht
NR 124
STATE Error
TCPIP 192.168.188.104
TYPE Shelly
READINGS:
2019-12-20 10:08:52 cloud disabled
2020-08-26 08:42:28 firmware v1.8.0
2020-08-27 08:40:44 network not connected
2020-08-27 08:39:39 relay off
2020-08-27 08:40:44 state Error
Attributes:
icon light_downlight
model shelly1
room Haus
Im log sehe ich folgendes
2020-08-27 08:43:30 Shelly SZ_SchrankLicht Error
2020-08-27 08:43:30 Shelly SZ_SchrankLicht network: not connected
2020-08-27 08:43:43 Shelly WK_Rollo Error
2020-08-27 08:43:43 Shelly WK_Rollo network: not connected
2020-08-27 08:46:59 Shelly EG_GangLicht network: <html>connected to <a href="http://192.168.188.104">192.168.188.104</a></html>
2020-08-27 08:46:59 Shelly EG_GangLicht off
Hat sich erledigt, war wohl ein shelly Problem. Inzwischen gibt eine 1.8.3, damit besteht das Problem nicht mehr.
Ich muss leider feststellen das es auch mit der 1.8 gravierende verbindungsprobleme gibt.
Bin ich der einzige mit dem Problem oder gibt es einen fix?
Hier ein log Auszug
2020.09.09 14:32:08 3: MQTT: MQTT_192.168.188.103_52392/shellyswitch25-687233 left us (keepalive check)
2020.09.09 14:32:18 3: MQTT: MQTT_192.168.188.102_53856/shelly1-2274F8 left us (keepalive check)
2020.09.09 14:32:18 3: MQTT: MQTT_192.168.188.104_59587/shelly1-C4ECA1 left us (keepalive check)
2020.09.09 14:32:58 3: MQTT: MQTT_192.168.188.105_52382/shellyswitch25-68FBDF left us (keepalive check)
2020.09.09 14:33:18 3: MQTT: MQTT_192.168.188.101_50926/shellyswitch-559C32 left us (keepalive check)
2020.09.09 14:33:37 3: MQTT2_DEVICE set EG_GangLicht off
2020.09.09 14:33:58 3: MQTT: MQTT_192.168.188.102_58958/shelly1-2274F8 left us (keepalive check)
2020.09.09 14:34:08 3: MQTT: MQTT_192.168.188.103_65286/shellyswitch25-687233 left us (keepalive check)
2020.09.09 14:34:59 3: MQTT2_DEVICE set SZ_SchrankLicht off
2020.09.09 14:35:23 3: MQTT2_DEVICE set OG_GangLicht off
2020.09.09 14:35:58 3: MQTT: MQTT_192.168.188.101_61535/shellyswitch-559C32 left us (keepalive check)
2020.09.09 14:35:58 3: MQTT: MQTT_192.168.188.104_61818/shelly1-C4ECA1 left us (keepalive check)
2020.09.09 14:36:08 3: MQTT: MQTT_192.168.188.103_55278/shellyswitch25-687233 left us (keepalive check)
2020.09.09 14:36:08 3: MQTT: MQTT_192.168.188.105_57959/shellyswitch25-68FBDF left us (keepalive check)
2020.09.09 14:36:08 3: MQTT: MQTT_192.168.188.102_52254/shelly1-2274F8 left us (keepalive check)
2020.09.09 14:38:06 3: MQTT2_DEVICE set KG_GangLicht off
2020.09.09 14:38:08 3: MQTT: MQTT_192.168.188.104_63123/shelly1-C4ECA1 left us (keepalive check)
2020.09.09 14:38:08 3: MQTT: MQTT_192.168.188.101_65200/shellyswitch-559C32 left us (keepalive check)
2020.09.09 14:38:11 3: MQTT2_DEVICE set EG_GangLicht off
2020.09.09 14:38:18 3: MQTT: MQTT_192.168.188.105_55481/shellyswitch25-68FBDF left us (keepalive check)
2020.09.09 14:38:18 3: MQTT: MQTT_192.168.188.103_51533/shellyswitch25-687233 left us (keepalive check)
Selbes problem mit dem shelly Modul ohne mqtt.
Welcher Shelly denn? Vielleicht Mal ein list vom device. Was zeigt denn die Signalstärke bei dem Shelly an?
Shelly 1 und 2.5
Hier ein 2.5er
Internals:
CID shellyswitch_559C32
DEF shellyswitch_559C32
DEVICETOPIC WK_Rollo
FUUID 5f4b9dd8-f33f-aa80-49dc-ced5ea3bf79c0c0b
IODev MQTT
LASTInputDev MQTT
MQTT_MSGCNT 71931
MQTT_TIME 2020-09-09 15:00:44
MSGCNT 71931
NAME WK_Rollo
NR 133
STATE 0
TYPE MQTT2_DEVICE
READINGS:
2020-08-30 14:38:58 actions_stats_skipped 0
2020-08-30 14:38:58 attrTemplateVersion 20200617
2020-09-09 08:19:44 automatic disabled
2020-08-30 14:38:58 cfg_changed_cnt 2
2020-08-30 14:38:58 cloud_connected false
2020-08-30 14:38:58 cloud_enabled false
2020-09-09 15:00:44 current stop
2020-09-09 15:00:44 energy 411
2020-08-30 14:38:58 fs_free 149847
2020-08-30 14:38:58 fs_size 233681
2020-09-09 14:38:14 fw_ver 20200827-065420/v1.8.3@4a8bc427
2020-08-30 14:38:58 has_update false
2020-09-09 14:38:14 id shellyswitch-559C32
2020-09-09 15:00:44 input0 0
2020-09-09 15:00:44 input1 0
2020-08-30 14:38:58 inputs_1_event
2020-08-30 14:38:58 inputs_1_event_cnt 0
2020-08-30 14:38:58 inputs_1_input 0
2020-08-30 14:38:58 inputs_2_event
2020-08-30 14:38:58 inputs_2_event_cnt 0
2020-08-30 14:38:58 inputs_2_input 0
2020-09-09 14:38:14 ip 192.168.188.101
2020-09-09 14:38:14 mac CC50E3559C32
2020-08-30 14:38:58 meters_1_counters_1 0.000
2020-08-30 14:38:58 meters_1_counters_2 0.000
2020-08-30 14:38:58 meters_1_counters_3 0.000
2020-08-30 14:38:58 meters_1_is_valid true
2020-08-30 14:38:58 meters_1_overpower 0.00
2020-08-30 14:38:58 meters_1_power 0.00
2020-08-30 14:38:58 meters_1_timestamp 1598798338
2020-08-30 14:38:58 meters_1_total 281
2020-09-09 14:38:14 model SHSW-21
2020-08-30 14:38:58 mqtt_connected true
2020-09-09 14:38:14 new_fw false
2020-09-09 14:38:14 online true
2020-09-09 15:00:44 pct 0
2020-09-09 15:00:44 power 0.00
2020-08-30 14:38:58 ram_free 36864
2020-08-30 14:38:58 ram_total 50296
2020-09-09 15:00:44 roller_0_energy 411
2020-09-09 15:00:44 roller_0_power 0.00
2020-09-09 15:00:44 roller_0_stop_reason normal
2020-08-30 14:38:58 rollers_1_calibrating false
2020-08-30 14:38:58 rollers_1_current_pos 90
2020-08-30 14:38:58 rollers_1_is_valid true
2020-08-30 14:38:58 rollers_1_last_direction close
2020-08-30 14:38:58 rollers_1_positioning true
2020-08-30 14:38:58 rollers_1_power 0.00
2020-08-30 14:38:58 rollers_1_safety_switch false
2020-08-30 14:38:58 rollers_1_state stop
2020-08-30 14:38:58 rollers_1_stop_reason normal
2020-08-30 14:38:58 serial 4491
2020-09-09 15:00:44 state 0
2020-08-30 14:38:58 time 14:38
2020-08-30 14:38:58 unixtime 1598798338
2020-08-30 14:38:58 update_has_update false
2020-08-30 14:38:58 update_new_version 20200827-065420/v1.8.3@4a8bc427
2020-08-30 14:38:58 update_old_version 20200827-065420/v1.8.3@4a8bc427
2020-08-30 14:38:58 update_status idle
2020-08-30 14:38:58 uptime 266775
2020-08-30 14:38:58 voltage 237.97
2020-08-30 14:38:58 wifi_sta_connected true
2020-08-30 14:38:58 wifi_sta_ip 192.168.188.101
2020-08-30 14:38:58 wifi_sta_rssi -63
2020-08-30 14:38:58 wifi_sta_ssid Dahoam
2020-08-30 14:38:58 x_mqttcom set announce
Attributes:
IODev MQTT
autoDevice Rollosteuerung
autoLimits 25-60|100
autoOrientation west
cmdIcon open:fts_shutter_up close:fts_shutter_down stop:fts_shutter_manual half:fts_shutter_50
comment Shelly 2.5 in Roller-Mode. 0=opened / 100=closed
devStateIcon { my $amp = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";; my $con = ReadingsVal($name,"state","unknown");; my $pic = $con eq "opening" ? 'fts_shutter_up@red' : $con eq "closing" ? 'fts_shutter_down@red' : $con eq "100" ? 'fts_shutter_100' : $con =~ /(\d)\d/ ? 'fts_shutter_'.$1.'0' : $con =~ /\b\d\b/ ? 'fts_shutter_10' : 'fts_shutter_updown';; my $show = "$amp" eq "gelb" ? "<a href=\"/fhem?cmd.dummy=set $name x_update&XHR=1\">".FW_makeImage("10px-kreis-".$amp)."</a>" : "<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage("10px-kreis-".$amp)."</a>";; "<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\"></a>".FW_makeImage($pic)." </div>"}
model shelly25_roller_invert_1
readingList shellies/shellyswitch-559C32/roller/0/pos:.* {'pct' => 100-$EVENT}
shellies/shellyswitch-559C32/status/0/rollers:.* power
shellies/shellyswitch-559C32/online:.* online
shellies/shellyswitch-559C32/announce:.* { json2nameValue($EVENT) }
shellies/announce:.* { $EVENT =~ m,..id...shellyswitch-559C32...mac.*, ? json2nameValue($EVENT) : return }
shellies/shellyswitch-559C32/roller/0:.* current
shellies/shellyswitch-559C32/roller/0:open {{'state' => 'opening'}}
shellies/shellyswitch-559C32/roller/0:close {{'state' => 'closing'}}
shellies/shellyswitch-559C32/roller/0/pos:.* {'state' => 100-$EVENT}
shellies/shellyswitch-559C32/input/1:.* input1
shellies/shellyswitch-559C32/input/0:.* input0
shellies/shellyswitch-559C32/relay/power:.* power
shellies/shellyswitch-559C32/relay/energy:.* energy
shellies/shellyswitch-559C32/temperature:.* temperature
shellies/shellyswitch-559C32/overtemperature:.* overtemperature
shellies/shellyswitch-559C32/roller/0/power:.* roller_0_power
shellies/shellyswitch-559C32/roller/0/energy:.* roller_0_energy
shellies/shellyswitch-559C32/temperature_f:.* temperature_f
shellyswitch_559C32:shellies/shellyswitch-559C32/info:.* { json2nameValue($EVENT) }
shellyswitch_559C32:shellies/shellyswitch-559C32/roller/0/stop_reason:.* roller_0_stop_reason
room Wohnküche
setList open:noArg shellies/shellyswitch-559C32/roller/0/command open
close:noArg shellies/shellyswitch-559C32/roller/0/command close
half:noArg shellies/shellyswitch-559C32/roller/0/command/pos 50
stop:noArg shellies/shellyswitch-559C32/roller/0/command stop
pct:slider,0,1,100 {"shellies/shellyswitch-559C32/roller/0/command/pos ".(100-$EVTPART1)}
x_recalibration:noArg shellies/shellyswitch-559C32/roller/0/command rc
x_update:noArg shellies/shellyswitch-559C32/command update_fw
x_mqttcom shellies/shellyswitch-559C32/command $EVTPART1
setStateList open close half stop pct
userReadings automatic
userattr autoOrientation autoLimits autoDevice
webCmd :open:close:half:stop:pct
Ich habe überall noch 1.6 oder 1.7 drin. Und werde mich natürlich im Moment hüten, in meinen produktiven Systemen 1.8 aufzuspielen. Da ich im Moment in Arbeit ersaufe, kann ich ein Testsystem nicht vor Anfang Oktober aufbauen..
Mein Tipp: Dimitar Dimitrov kontaktieren (via Facebook), ist einer der Chefs von Allterco Robotics. Und ihn mal mit dem Abbruchproblem konfrontieren.
LG
pah
Moin,
hm, ist mir auch aufgefallen - aber ich habe es bisher auf eine Umstellung in meinem Netz geschoben, wo ich u.a. auch alle Shellys auf einen anderen Router gelegt habe. Die WLan-Stärke sieht aber ähnlich aus ... Vlt. legen sich die Shellys ja schlafen, und brauchen zu lange, um wieder ins Netz zu kommen!?
Gruß, Christoph
mit Fehler
Internals:
DEF 192.168.5.135
DURATION 0
FUUID 5de800df-f33f-378b-2882-5a288075fee07f20
FVERSION 36_Shelly.pm:v2.13.0-s21949/2020-05-16
INTERVAL 60
NAME shelly.Wohnzimmer.Soundbar
NR 1779
STATE Error
TCPIP 192.168.5.135
TYPE Shelly
READINGS:
2020-03-13 17:59:07 cloud disabled
2020-09-28 21:46:41 energy 2504.7
2020-08-28 18:03:47 firmware v1.8.3
2020-09-29 08:39:19 network not connected
2020-09-28 21:45:40 overpower 0
2020-09-28 21:45:41 power 0
2020-09-28 21:45:40 relay off
2020-09-29 08:39:19 state Error
Attributes:
event-on-change-reading state,network,firmware
model shellyplug
room Wohnzimmer
und einer mit Verbindung (direkt daneben...)Internals:
DEF 192.168.5.242
DURATION 0
FUUID 5e04c3ff-f33f-378b-3bc0-f10366806254a32f
FVERSION 36_Shelly.pm:v2.13.0-s21949/2020-05-16
INTERVAL 60
NAME shelly.Wohnzimmer.Sonos
NR 1790
STATE off
TCPIP 192.168.5.242
TYPE Shelly
READINGS:
2020-03-13 17:59:07 cloud disabled
2020-09-28 18:10:31 energy 347.6
2020-08-28 18:03:07 firmware v1.8.3
2020-09-27 15:31:23 network <html>connected to <a href="http://192.168.5.242">192.168.5.242</a></html>
2020-09-28 18:09:29 overpower 0
2020-09-28 18:09:31 power 0
2020-09-28 18:09:29 relay off
2020-09-28 18:09:29 state off
Attributes:
event-on-change-reading state,network,firmware
model shellyplug
room Wohnzimmer
Beides Shelly Plug S.
Hallo Pah,
ich habe gerade in der Documentation beim Shelly 1 gelesen, das man einen konstanten Wert für power hinterlegen kann.
Shelly1: /settings/power/0
Parameters
Parameter Type Description
power number Shelly1 only Set user power constant to display in meters when relay is on, 0..4000W
power wird aber als Reading nicht angezeigt.
Ist das bereits in deinem Modul enthalten und mir fehlt ein Update oder ist das eine neue Erweiterung die du noch nachpflegst ?
LG
Bombardi
Da der Shelly 1 keine Leistungsmessung durchführt, macht es auch keinen Sinn, die Konstante jedes Mal neu abzufragen. Wer unbedingt diesen festen Wert in den Readings haben will, soll sich ein userReading bauen, das je nach Schaltzustand diesen festen Wert oder Null anzeigt.
Merke: Wer viel misst, misst viel Mist.
LG
pah
Hallo,
beim meinen Shelly Dimmer wird kein Power/Meter Reading angezeigt. Beim Shelly1PM/2.5 werden diese Readings angezeigt. Woran kann das liegen?
Internals:
DEF 192.168.2.213
DURATION 0
FUUID 5f646da3-f33f-0254-dd54-006592c17d48215c
INTERVAL 5
NAME KG_Flur_Dimmer
NR 489
STATE off
TCPIP 192.168.2.213
TYPE Shelly
Helper:
DBLOG:
state:
LOG_Db:
TIME 1601527054.91513
VALUE off
READINGS:
2020-09-18 10:20:08 cloud disabled
2020-09-18 10:20:08 firmware v1.8.4
2020-09-30 10:53:34 network <html>connected to <a href="http://192.168.2.213">192.168.2.213</a></html>
2020-09-27 16:02:36 pct 25
2020-10-01 06:37:34 state off
Attributes:
DbLogExclude .*
DbLogInclude state
group Licht
interval 5
model shellydimmer
room 10_KG,90_Licht,Shelly
shellyuser root
sortby 10
webCmd pct
Bin für jeden Tip dankbar
Gruss
Michl
Zitat von: caldir65 am 29 September 2020, 08:48:18
Moin,
hm, ist mir auch aufgefallen - aber ich habe es bisher auf eine Umstellung in meinem Netz geschoben, wo ich u.a. auch alle Shellys auf einen anderen Router gelegt habe. Die WLan-Stärke sieht aber ähnlich aus ... Vlt. legen sich die Shellys ja schlafen, und brauchen zu lange, um wieder ins Netz zu kommen!?
Gruß, Christoph
mit Fehler
Internals:
DEF 192.168.5.135
DURATION 0
FUUID 5de800df-f33f-378b-2882-5a288075fee07f20
FVERSION 36_Shelly.pm:v2.13.0-s21949/2020-05-16
INTERVAL 60
NAME shelly.Wohnzimmer.Soundbar
NR 1779
STATE Error
TCPIP 192.168.5.135
TYPE Shelly
READINGS:
2020-03-13 17:59:07 cloud disabled
2020-09-28 21:46:41 energy 2504.7
2020-08-28 18:03:47 firmware v1.8.3
2020-09-29 08:39:19 network not connected
2020-09-28 21:45:40 overpower 0
2020-09-28 21:45:41 power 0
2020-09-28 21:45:40 relay off
2020-09-29 08:39:19 state Error
Attributes:
event-on-change-reading state,network,firmware
model shellyplug
room Wohnzimmer
und einer mit Verbindung (direkt daneben...)Internals:
DEF 192.168.5.242
DURATION 0
FUUID 5e04c3ff-f33f-378b-3bc0-f10366806254a32f
FVERSION 36_Shelly.pm:v2.13.0-s21949/2020-05-16
INTERVAL 60
NAME shelly.Wohnzimmer.Sonos
NR 1790
STATE off
TCPIP 192.168.5.242
TYPE Shelly
READINGS:
2020-03-13 17:59:07 cloud disabled
2020-09-28 18:10:31 energy 347.6
2020-08-28 18:03:07 firmware v1.8.3
2020-09-27 15:31:23 network <html>connected to <a href="http://192.168.5.242">192.168.5.242</a></html>
2020-09-28 18:09:29 overpower 0
2020-09-28 18:09:31 power 0
2020-09-28 18:09:29 relay off
2020-09-28 18:09:29 state off
Attributes:
event-on-change-reading state,network,firmware
model shellyplug
room Wohnzimmer
Beides Shelly Plug S.
Ich hab das Problem an allen 5xShellys (1&2.5). Leider bekomme ich es nicht in den Griff.
Ich bin mir mittlerweile sicher das es kein WLAN Problem ist, da ich am Router im log nie reconnects der shellies habe.
Es muss ein fhem Problem sein.
Sorry, aber für mich nicht nachvollziehbar.
Ich habe jetzt alle meine Shelly-Devices mit der neuen Firmware versehen. Auch die sind teilweise dicht nebeneinander verbaut - etwa vier Stück Shelly 2.5 mit den IP-Adressen .164-167 in einer Vierfachdose, 3m davon entfernt zwei weitere mit .163 und .162. Keinerlei Problem, alle mit dem Shelly-Modul sauber ansteuerbar.
Ab und zu - sagen wir 1x pro Tag - gibt es von einem der ungünstiger eingebauten Shelly-Devices eine timeout-Meldung im Log, weil der Return von HttpUtilsNonBlockingGet nicht innerhalb der normalen Timeout-Zeit erfolgt. Diese Meldung stört mich zwar nicht, aber man könnte noch ein für jedes Device setzbares Timeout einbauen. Bevor ich das mache, bitte einfach mal selbst ausprobieren: Im Modul 36_Shelly.pm in den Zeilen 877-880 ersetzen
HttpUtils_NonblockingGet({
url => $url,
callback=>sub($$$){ Shelly_status($hash,$_[1],$_[2]) }
});
durch
HttpUtils_NonblockingGet({
url => $url,
timeout => 5,
callback=>sub($$$){ Shelly_status($hash,$_[1],$_[2]) }
});
LG
pah
Zitat von: Prof. Dr. Peter Henning am 22 Juli 2020, 05:35:08
Beim I3 muss ich mir auch noch das API genauer ansehen.
LG
pah
Hallo,
ich habe mir auch mal, nach oberflächlicher Recherche, so ein i3 kommen lassen.
Allerdings habe ich nun festgestellt, dass dieser nicht im Modul implementiert ist.
Nach etwas gründlicheren Recherche habe ich festgestellt, dass einige User den i3 nutzen. Allerdings ist mir nicht ganz klar wie.
Über set-Befehle im shelly?
Besteht noch die Möglichkeit, dass der i3 im Modul aufgenommen wird?
Ich denke, dass Ding ist echt gut und hätte es verdient out-of-the-box zu funktionieren. ;) ;D
Vielen Dank für Rückmeldung.
Bis denn
SouzA
ZitatÜber set-Befehle im shelly?
Ja, natürlich.
Und genau wie beim Shelly-Button bin ich da eher zurückhaltend - diese Teile lassen sich viel einfacher direkt in der Web-Oberfläche mit Befehlen ausstatten, die z.B. ein Dummy-Device schalten, als dies noch über FHEM zu steuern. Denn die i3 senden ja von sich aus etwas, und müssen nicht abgefragt (oder sonstwie gesteuert) werden.
Da FHEM also nur die Rolle eines passiven Empfängers spielt, reicht die REST-Schnittstelle vollkommen aus - und wer es komplizierter mag, soll halt auf MQTT setzen.
Sowohl die Bedienung der REST-Schnittstelle von FHEM, als auch MQTT funktionieren "out-of-the-box", weil man den Shelly sowieso auf seiner eigenen Web-Oberfläche im WLAN anmelden muss.
LG
pah
Hallo,
Vielen Dank für die Rückmeldung.
Ich hab es über einen Set-Befehl versucht... (Dummy ansteuern)
Allerdings hängt sich der i3 dann immer auf und startet neu. Bin grad unterwegs... Poste nachher mal den Befehl.
Was ist die REST Schnittstelle? Ich find dazu irgendwie nix aussagekräftiges.
Vielen Dank und bis denn
SouzA
REST-API:
https://forum.fhem.de/index.php?topic=14491.0
Rückgabewerte sind aber unnötig, also reduziert sich der Aufruf des REST-API auf http://192.168.xxx.yyy/fhem?cmd=(irgendein Kommando mit URL Encoding)&XHR=1
LG
pah
Hallo,
funktioniert nun ;)
Danke und bis denn
SouzA
Hallo,
ich habe gerade einen ShellyPlug (FW 20200827-070415/v1.8.3) eingebunden. Ohne weitere Einstellungen vorzunehmen, gab es zwei Warnmeldungen.
PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/36_Shelly.pm line 1328
PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/36_Shelly.pm line 1338
Das Schalten an sich funktioniert. Kann ich diese ignorieren oder sollte ich Probleme im Betrieb erwarten?
Nachtrag: Wer lesen kann ist klar im Vorteil. Ich hatte das Attribut model noch nicht gesetzt.
VG
Tobi
Hallo PAH,
besteht die Möglichkeit, ein disabled-Attribut zu bekommen ? Ich habe ein paar Shellys, die nur temporär in Betrieb sind und wenn ich die dann bei Nichtbenutzung nicht in der cfg auskommentiere, dann bekomme ich immer im Log einen Eintrag, dass das Device nicht erreichbar ist und mein Freeze-Wert geht leicht hoch. Oder gibts eine andere Möglichkeit, dass zu umgehen ?
Grüße
Christian
Polling-Intervall auf Null setzen, ganz einfach.
LG
pah
Top, danke für die schnelle Antwort :-)
Ich habe schon mehrere ShellyPlugS erfolgreich in FHEM eingebunden.
Jetzt habe ich mir einen Shelly Dimmer 2 gekauft und erfolgreich integriert.
Allerdings fehlt das Reading "power" - die Leistung ist aber auf der Shelly-Weboberfläche zu sehen. Das Attribut "model" habe ich auf "shellydimmer" gesetzt.
Ist das evtl. ein neues Feature des Shelly Dimmer 2?
Ja.
LG
pah
Dann bitte ich hiermit den Modul-Autor ganz freundlich, das neue Feature ins Shelly-Modul zu integrieren. :)
Vielen Dank vorab!
Das im Modul hinterlegte API für shellydimmer hat ein Reading "power". Da ich allerdings nicht Hardware nur kaufe, um sie in FHEM zu integrieren, habe ich die Änderung des API an dieser Stelle nicht mitbekommen.
Mit der angehängten Version des Moduls sollte es funktionieren, bitte testen.
LG
pah
Vielen Dank für die schnelle Reaktion.
Leider hat es nicht funktioniert.
Beim FHEM-Start bekomme ich Fehlermeldungen und alle meinen Shell-Devices sind verschwunden.
Global symbol "$old_pwd" requires explicit package name (did you forget to declare "my $old_pwd"?) at ./FHEM/36_Shelly.pm line 238.
2020.11.30 10:41:44 0: Global symbol "$old_pwd" requires explicit package name (did you forget to declare "my $old_pwd"?) at ./FHEM/36_Shelly.pm line 238.
2020.11.30 10:41:44 3: myMQTT_Server: port 1883 opened
2020.11.30 10:41:45 1: PERL WARNING: Subroutine Shelly_Initialize redefined at ./FHEM/36_Shelly.pm line 129.
2020.11.30 10:41:45 1: PERL WARNING: Subroutine Shelly_Define redefined at ./FHEM/36_Shelly.pm line 152.
2020.11.30 10:41:45 1: PERL WARNING: Subroutine Shelly_Delete redefined at ./FHEM/36_Shelly.pm line 200.
2020.11.30 10:41:45 1: PERL WARNING: Subroutine Shelly_Undef redefined at ./FHEM/36_Shelly.pm line 215.
2020.11.30 10:41:45 1: reload: Error:Modul 36_Shelly deactivated:
Global symbol "$old_pwd" requires explicit package name (did you forget to declare "my $old_pwd"?) at ./FHEM/36_Shelly.pm line 238.
2020.11.30 10:41:45 0: Global symbol "$old_pwd" requires explicit package name (did you forget to declare "my $old_pwd"?) at ./FHEM/36_Shelly.pm line 238.
2020.11.30 10:41:45 1: reload: Error:Modul 36_Shelly deactivated:
Global symbol "$old_pwd" requires explicit package name (did you forget to declare "my $old_pwd"?) at ./FHEM/36_Shelly.pm line 238.
2020.11.30 10:41:45 0: Global symbol "$old_pwd" requires explicit package name (did you forget to declare "my $old_pwd"?) at ./FHEM/36_Shelly.pm line 238.
2020.11.30 10:41:45 1: reload: Error:Modul 36_Shelly deactivated:
Global symbol "$old_pwd" requires explicit package name (did you forget to declare "my $old_pwd"?) at ./FHEM/36_Shelly.pm line 238.
2020.11.30 10:41:45 0: Global symbol "$old_pwd" requires explicit package name (did you forget to declare "my $old_pwd"?) at ./FHEM/36_Shelly.pm line 238.
Mit der alten Version von 36_Shelly läuft's jetzt wieder - allerdings bekomme ich beim Start auch damit die Warnung:
PERL WARNING: Subroutine Shelly_Undef redefined at ./FHEM/36_Shelly.pm line 200.
Hallo,
bei mir ist das gleiche, alle Shellys ohne "power" reading (Shelly1) werden nicht mehr angezeigt/verschwunden
Gruss
...Shelly 1 mit Power Reading ??? Beim 2 und 2.5 kenne ich das, aber nicht beim Shelly1. Mein Shelly1 hat das auch nicht im WebIf, die anderen wohl... Beim Shelly 2 mit FW v1.6.0 ist auch im FHEM das Power-Reading drin, heute morgen noch gefüttert worden. Beim 2.5er gibts Power (letztes Reading gestern) und Power_0 (letztes Reading heute), FW v1.6.0
michlm schreibt ja, dass eben Shellys OHNE power Reading "weg" sind, also in seinem Fall alle Shelly1...
Zumindest lese ich das so... ;)
Gruß, Joachim
OK, ja, könnte auch so verstanden werden, dann bin ich leider in die falsche Richtung gelaufen ;-)
Servus,
Joachim hat es richtig gelesen ;)
Michl
Leute, das ist ein typischer Fall von "Wir zünden eine Nebelkerze". Dieser Fehler hat _gar nichts_ mit "power" zu tun, und es sollten tatsächlich alle Devices verschwunden sein (also ist der Post von michlm mit Sicherheit nicht richtig). Übrigens sind solche Effekte der Grund dafür, dass ich schreibe "bitte testen".
Sondern der neue Fehler hat auschließlich mit einem Fehler im FHEMWiki für Developer zu tun - nämlich die Übernahme des Passworts bei einem Rename. Diesen Fehler habe ich, wie sollte es anders sein, einfach ohne nachzudenken übernommen...
Sollte in der angehängten Version behoben sein - und im FHEMWiki habe ich es auch gleich verbessert.
LG
pah
Die neue Version zeigt beim Start keine Fehler oder Warnungen.
ShellyPlugS Devices funktionieren einwandfrei.
Allerdings taucht bei meinem Dimmer kein Reading "power" auf - auch nach ca. 10 Minuten warten.
Update: Wenn ich get ... registers ausführe, erhalte ich beim Dimmer nichts zurück.
Moin,
kann JWRu bestätigen, es funktioniert weiterhin alles, der Dimmer will jedoch kein Power Reading befüllen, noch seine "registers".
edit:
die register für den dimmer sind einfach nicht definiert und können aber auch nur befüllt werden, wenn
es in den zeilen 430 und 458 light, nicht lights heißt
und für power fehlt ab Zeile 1060 einfach der meters Teil.
for( my $i=0;$i<$meters;$i++){
$subs = ($meters == 1) ? "" : "_".$i;
$power = $jhash->{'meters'}[$i]{'power'};
$energy = int($jhash->{'meters'}[$i]{'total'}/6)/10;
readingsBulkUpdateIfChanged($hash,"power".$subs,$power);
readingsBulkUpdateIfChanged($hash,"energy".$subs,$energy);
}
Gruß
Markus
edit 2:
wer testen mag - anbei.
@trallala: ::) ::)
Zu 1: Von den Registern war bisher noch nicht die Rede.
Zu 2.: Granatenmäßiger Unsinn. Die gestern gepostete Version enthält genau diese Abfragen bzw. Ausgaben in den Zeilen 1052/53 und 1057/58. Wobei in Zeile 1053 noch ein Copy-Paste-Error steckt, der in der angehängten Version behoben ist.
Edit: Bitte keine selbst geänderten Module unter dem gleichen Namen posten - unbedingt aus dem vorigen Post löschen.
@JWRu: Bitte mal den Inhalt von http://<ip-device>/status posten
LG
pah
ZitatVon den Registern war bisher noch nicht die Rede.
Das war mir schon klar. Ich dachte, es hilft vielleicht bei der Fehlersuche - tut es aber offenbar nicht.
ZitatBitte mal den Inhalt von http://<ip-device>/status posten
{"wifi_sta":{"connected":true,"ssid":"XXXXXXXXX","ip":"XXXXXXXXX","rssi":-66},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":false},"time":"13:49","unixtime":1606830543,"serial":1240,"has_update":false,"mac":"XXXXXXXXX","cfg_changed_cnt":0,"actions_stats":{"skipped":0},"lights":[{"ison":true,"source":"http","has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"mode":"white","brightness":60}],"meters":[{"power":41.95,"overpower":0.00,"is_valid":true, "timestamp":1606830543,"counters":[10.281, 0.000, 0.000],"total":948}],"inputs":[{"input":0,"event":"","event_cnt":0},{"input":0,"event":"","event_cnt":0}],"tmp":{"tC":36.71,"tF":98.08, "is_valid":true},"calibrated":true,"calib_progress":0,"calib_status":0,"wire_mode":0,"overtemperature":false,"loaderror":0,"overpower":false,"debug":0,"update":{"status":"idle","has_update":false,"new_version":"20201124-092706/v1.9.0@57ac4ad8","old_version":"20201124-092706/v1.9.0@57ac4ad8"},"ram_total":48368,"ram_free":35388,"fs_size":233681,"fs_free":113954,"uptime":72686}Ich habe die Ausgabe an den XXXXX..-Stellen anonymisiert.
Hm - wundert mich. Sicher, dass die oben gepostete aktuelle (Test-)Version des Moduls aktiv ist?
Denn in dem JSON-Code taucht der Wert
Zitat"meters": [{
"power": 41.95,
"overpower": 0,
"is_valid": true,
"timestamp": 1606830543,
"counters": [
10.281,
0,
0
],
"total": 948
}],
auf, und wird vom Modul in der Zeile
Zitat$power = $jhash->{'meters'}[$i]{'power'};
mit $i=0 abgefragt.
LG
pah
Sorry - es war noch die Version von gestern 17:30 Uhr aktiv.
Mit der Version von heute ist das Reading "power" aufgetaucht und wird auch gefüllt.
Vielen Dank!
OK, dann bitte noch ein Test mit der angehängten Version - die holt sich auch das korrekte Reading für energy, und ein Setzen sollte auch möglich sein.
Allterco Robotics hat hier eine üble Inkonsistenz im API - das Array heißt einmal "lights" und einmal "light".
LG
pah
ZitatOK, dann bitte noch ein Test mit der angehängten Version - die holt sich auch das korrekte Reading für energy, und ein Setzen sollte auch möglich sein.
Reading "energy" ist da und wird gefüllt.
Wie man das setzt, weiß ich nicht - in der Dropdown-Liste für "set" taucht nichts auf.
Neinnein - das wird nicht gesetzt, sonder ist die über die Zeit integrierte Leistung.
LG
pah
Ok, habe ich falsch verstanden - wird vom Gerät gesetzt.
Damit geht jetzt alles ... bis auf get registers ;-) - brauche ich aber nicht.
Vielen Dank nochmal!
Ich habe jetzt doch noch ein anderes Problem mit dem Dimmer:
Da ich den Dimmer auch lokal über Taster bedienen will, habe ich die "Hit"-URLs im Shelly gesetzt.
Die Befehle kommen auch in FHEM an. Wenn ich den Shelly über den Taster schalte, kommt im Event Monitor so etwas an:
2020-12-02 16:06:47 Shelly ShellyDimmer01 button_: on
2020-12-02 16:06:48 Shelly ShellyDimmer01 button_: off
2020-12-02 16:06:48 Shelly ShellyDimmer01 out_on
2020-12-02 16:06:52 Shelly ShellyDimmer01 button_: on
2020-12-02 16:06:53 Shelly ShellyDimmer01 button_: off
2020-12-02 16:06:53 Shelly ShellyDimmer01 out_off
Am State des FHEM Device tut sich aber nichts, das wird erst beim nächsten periodischen Update aktualisiert.
Zitat... bis auf get registers ;-)
Wieso? Das sollte gehen.
ZitatAm State des FHEM Device tut sich aber nichts, das wird erst beim nächsten periodischen Update aktualisiert.
Natürlich nicht - warum auch, wenn der Button u.U. etwas ganz Anderes schalten soll? Das muss man schon mit einem notify entsprechend abfangen.
LG
pah
ZitatWieso? Das sollte gehen.
Beim Dimmer erhalte ich keine Registernamen zurück, beim Plug sehr wohl (siehe angehängte Bildschirmfotos).
Ich brauche die Button-Rückmeldung eigentlich nicht - die hatte ich nur zum Testen aktiviert.
Ich hatte mir vorgestellt, dass ich mit der Out-URL das FHEM-Device dazu bringen könnte, die Werte sofort zu aktualisieren und nicht erst nach INTERVALL Sekunden.
Ich kann ja auch mit einem notify wohl keine sofortige Aktualisierung anstoßen.
ZitatIch hatte mir vorgestellt, dass ich mit der Out-URL das FHEM-Device dazu bringen könnte, die Werte sofort zu aktualisieren und nicht erst nach INTERVALL Sekunden.
Natürlich geht das. In den REST-Call vom Shelly-Button an FHEM einfach einbauen "setreading <Device> state off" oder on.
LG
pah
So einfach geht es nicht. Immer, wenn sich der Ausgang ändert, kommt "out_on". Also auch, wenn der Dimmer schon an ist und man dimmt.
Leider habe ich aber in dem Rest-Call keine Zugriff auf "pct" bzw. "brightness". Den Wert hätte ich gerne auch aktuell, nicht nur state.
P.S. Mit ist doch noch eine "Holzhammer-Methode" eingefallen: Ein notify auf "out_on" setzt kurzzeitig das Attribut "interval" auf 1 und dann wieder auf den Standardwert.
Nicht doch, es reicht das Kommando "get status".
LG
pah
Zitates reicht das Kommando "get status".
Dann kommt ein Popup-Fenster, das weggeklickt werden muss.
P.S Ich hab's jetzt mit einem notify gelöst, funktioniert super:
define notify_ShellyDimmer_refresh notify ShellyDimmer.*:out_.* attr $NAME interval 1;; sleep 1;; attr $NAME interval 60;; save
Hallo,
ich hab gestern einen Shelly 1 in Betrieb genommen und in FHEM eingebunden:
Internals:
DEF 192.168.178.73
DURATION 0
FUUID 5fc7b7d0-f33f-9ecb-769f-b7ce62778d38d763
INTERVAL 60
NAME shelly.Balkon
NR 385
STATE off
TCPIP 192.168.178.73
TYPE Shelly
OLDREADINGS:
READINGS:
2020-12-02 16:50:40 cloud disabled
2020-12-02 16:50:40 firmware v1.9.0
2020-12-02 22:33:37 network <html>connected to <a href="http://192.168.178.73">192.168.178.73</a></html>
2020-12-03 07:11:32 relay off
2020-12-03 07:11:32 state off
Attributes:
event-on-change-reading .*
model shelly1
webCmd :
Leider habe ich jetzt minütlich eine Warnung im Logfile:
2020.12.03 09:36:47 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4818.
2020.12.03 09:36:47 1: stacktrace:
2020.12.03 09:36:47 1: main::__ANON__ called by fhem.pl (4818)
2020.12.03 09:36:47 1: main::readingsBulkUpdateIfChanged called by /opt/fhem/FHEM/36_Shelly.pm (965)
2020.12.03 09:36:47 1: main::Shelly_status called by /opt/fhem/FHEM/36_Shelly.pm (919)
2020.12.03 09:36:47 1: main::__ANON__ called by /opt/fhem/FHEM/HttpUtils.pm (639)
2020.12.03 09:36:47 1: main::__ANON__ called by fhem.pl (752)
2020.12.03 09:37:48 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4818.
2020.12.03 09:37:48 1: stacktrace:
2020.12.03 09:37:48 1: main::__ANON__ called by fhem.pl (4818)
2020.12.03 09:37:48 1: main::readingsBulkUpdateIfChanged called by /opt/fhem/FHEM/36_Shelly.pm (965)
2020.12.03 09:37:48 1: main::Shelly_status called by /opt/fhem/FHEM/36_Shelly.pm (919)
2020.12.03 09:37:48 1: main::__ANON__ called by /opt/fhem/FHEM/HttpUtils.pm (639)
2020.12.03 09:37:48 1: main::__ANON__ called by fhem.pl (752)
Ich hab gelesen dass andere dieses Problem nur beim Neustart hatten, aber das ist hier offensichtlich nicht der Fall.
Was kann ich tun?
ZitatDann kommt ein Popup-Fenster, das weggeklickt werden muss.
Aber doch nicht, wenn ich das über die REST-Schnittstelle anstoße.
ZitatWas kann ich tun?
Die Anleitung zu "event-on-change-reading" lesen und verstehen.
LG
pah
Häh? Was ist denn das bitte für eine Antwort? Was hat den event-on-change-reading damit zu tun?
Anyway, der Fehler liegt im Modul:
Im Status eines Shelly 1 gibts kein Attribut "overpower", das gibts nur beim Shelly 1PM.
Das Modul macht hier aber keine Unterscheidung.
Fix:
--- /opt/fhem/FHEM/36_Shelly.pm2020-12-03 19:44:58.869791001 +0100
+++ 36_Shelly.pm 2020-12-03 19:44:58.869791001 +0100
@@ -962,7 +962,9 @@
$ison =~ s/1|(true)/on/;
$overpower = $jhash->{'relays'}[$i]{'overpower'};
readingsBulkUpdateIfChanged($hash,"relay".$subs,$ison);
+ if($overpower){
readingsBulkUpdateIfChanged($hash,"overpower".$subs,$overpower);
+ }
if($model =~ /shelly(1|(plug)).*/){
readingsBulkUpdateIfChanged($hash,"state",$ison)
}else{
ZitatAber doch nicht, wenn ich das über die REST-Schnittstelle anstoße.
Das stimmt. Sorry, ich hatte den Befehl erstmal aus FHEM ausprobiert, bevor ich alle URLs ändere.
By the way:
Die Output-On URL wird getriggert, wenn der Dimmer eingeschaltet ist und man ihn über die Weboberfläche dimmt, nicht aber beim Dimmen über den angeschlossenen Taster.
Man muß also auch die Button-URLs für den Refresh verwenden.
Danke ersteinmal für das Shelly Modul. Jedoch ist es bisher das einzigste Modul, welches NUR über die IP und nicht über den Hostname kommunizieren kann.
Bitte abändern.
ZitatBitte abändern.
Nö.
LG
pah
Zitat von: max333 am 17 Dezember 2020, 16:12:45
Bitte abändern.
...wenn man hier neu ist, muss man ggf. nochmal an der Ausdrucksweise arbeiten, vielleicht bekommt man dann auch eine positivere Antwort....
Hallo,
ich habe nach wie vor das Problem, dass meine Shelly1 folgende Warnings im Log erzeugen:
2020.12.18 13:55:58 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4825.
2020.12.18 13:55:58 1: stacktrace:
2020.12.18 13:55:58 1: main::__ANON__ called by fhem.pl (4825)
2020.12.18 13:55:58 1: main::readingsBulkUpdateIfChanged called by ./FHEM/36_Shelly.pm (965)
2020.12.18 13:55:58 1: main::Shelly_status called by ./FHEM/36_Shelly.pm (919)
2020.12.18 13:55:58 1: main::__ANON__ called by FHEM/HttpUtils.pm (639)
2020.12.18 13:55:58 1: main::__ANON__ called by fhem.pl (755)
Soweit ich dass sehe wird in Zeile 965 der Parameter "overpower" abgefragt, welche von den 1ern nicht geliefert wird.
readingsBulkUpdateIfChanged($hash,"overpower".$subs,$overpower);
Ich kommentiere die Zeile jetzt immer aus, da ich nur Shelly1 habe. In der Zeile drauf würde aber sowieso abhängig vom Modell (1/plug) einer Unterscheidung getroffen.
Man könnte die "overpower" Abfrage einfach in den entsprechenden "if"-Zweig verschieben.
Oder habe ich jetzt irgendwas falsch konfiguriert oder übersehe etwas?
(FHEM und Shelly heute auf aktuellste Version geupdated)
Danke & Gruß,
Jörg
Gleiches Problem bei mir auch.
Ich hab weiter oben auch einen Patch gepostet, aber der Modulautor hat entweder keine Zeit oder keine Lust das zu ändern :(
@Adimarantis: Sehe ich mir an - da ich aktuell keine 1er in Betrieb habe, fällt mir das nicht auf.
LG
pah
@KyleK:
ZitatModulautor hat entweder keine Zeit oder keine Lust
Jedenfalls kein Interesse, halbgare Patchvorschläge zu übernehmen.Vorschlag: Auf andere Software oder andere Hardware wechseln.
@pah, ich verstehe nicht warum du mit deiner überheblichen Art andauernd (neue) Nutzer vergraulst?
Was bitte hast du davon?
Wenn mein Patch halbgar ist, dann tut mir das leid, meine Perl-Kentnisse sind basic. Dann machs halt besser. Für meinen einen Shelly1 funktioniert es wie erwartet.
Und: Nur weil du meinen Patch nicht magst werde ich kaum das System wechseln.
Auch finde die Kommunikation des Modulautors gewöhnungsbedürftig. Es gibt halt bei FHEM eine große Bandbreite an Mitwirkenden.
Auf der anderen Seite machen alle Modulautoren das freiwillig in ihrer Freizeit. Von daher kann man aus meiner Sicht als Anwender keine Forderungen stellen.
Wer mit dem Modul nicht zufrieden ist, kann ja immer noch zu MQTT wechseln.
ZitatWer mit dem Modul nicht zufrieden ist, kann ja immer noch zu MQTT wechseln.
Eben, ich bitte darum. Siehe den allerersten Post in diesem Thread. Und wenn wir dann noch auf alle Teilnehmer verzichten, die sich zum Richter über andere Menschen berufen fühlen, kann das auch etwas werden.
LG
pah
Ich verwende viele verschiedene Module von FHEM, aber ich kenne bisher nur das 36_Shelly.pm, welches keinen Hostnamen akzeptiert.
Früher oder später stolpert jeder über eine neu zugewiesene IP...
Für alle die, die den Hostnamen oder die IP nutzen wollen:
alle {TCPIP} durch {host} ersetzen und momentan bei den Zeilen 158 und 159 eine Raute am Anfang hinzufügen, muss dann so aussehen:
# return "[Shelly] Invalid IP address ".$a[2]." of Shelly device"
# if( $a[2] !~ m|\d\d?\d?\.\d\d?\d?\.\d\d?\d?\.\d\d?\d?(\:\d+)?| );
zum Schluss
reload 36_Shelly.pm
Leider muss das nach jedem Update wiederholt werden bis es endlich eingepflegt wird.
Zitatbis es endlich eingepflegt wird.
Oh, das kann bis zum Sankt Nimmerleinstag dauern...
@Adimarantis: Auf Grund der netten Anfrage war es mir eine Freude, das Problem zu beheben.
LG
pah
Zitat von: max333 am 20 Dezember 2020, 13:56:42
Früher oder später stolpert jeder über eine neu zugewiesene IP...
Für alle die, die den Hostnamen oder die IP nutzen wollen:
...
Leider muss das nach jedem Update wiederholt werden bis es endlich eingepflegt wird.
Oder in der Box / im Router dem Gerät eben eine feste IP zuweisen.
Moin,
mal was ganz anderes: gibt es evtl. ein Changelog zum Modul? Einfach mal aus Interesse gefragt
Gruß, Christoph
Zitat von: caldir65 am 21 Dezember 2020, 16:30:50
Moin,
mal was ganz anderes: gibt es evtl. ein Changelog zum Modul? Einfach mal aus Interesse gefragt
Gruß, Christoph
https://svn.fhem.de/trac/log/trunk/fhem/FHEM/36_Shelly.pm?rev=23398
Es gibt ja inzwischen auch Bulbs von Shelly.
Ist vorgesehen, diese in das Modul aufzunehmen?
Zitat von: Prof. Dr. Peter Henning am 20 Dezember 2020, 18:54:53
@Adimarantis: Auf Grund der netten Anfrage war es mir eine Freude, das Problem zu beheben.
Besten Dank. Hab es jetzt eingespielt und sehe keine Meldungen mehr.
Gruß,
Jörg
Hallo,
lese ich das richtig, das neue Shelly Modul kann Hostnamen? Dann aus meiner Ecke danke dafür ;D
Wenn ich bei meinem Plug die IP in den Namen ändere, dann kommt eine Fehlermeldung.
[Shelly] Invalid IP address trocknerzusatz of Shelly device
Btw, habe vorher ein update all gemacht und einen Reboot, der Ping von dem FHEM Rechner auf den Plugnamen funktioniert.
Grüße Peter
Zitat von: Peteruser am 30 Dezember 2020, 17:06:27
Hallo,
lese ich das richtig, das neue Shelly Modul kann Hostnamen? Dann aus meiner Ecke danke dafür ;D
Wenn ich bei meinem Plug die IP in den Namen ändere, dann kommt eine Fehlermeldung.
[Shelly] Invalid IP address trocknerzusatz of Shelly device
Btw, habe vorher ein update all gemacht und einen Reboot, der Ping von dem FHEM Rechner auf den Plugnamen funktioniert.
Grüße Peter
Nein, Du liest falsch ;)
Zitat von: Prof. Dr. Peter Henning am 20 Dezember 2020, 18:54:53
Oh, das kann bis zum Sankt Nimmerleinstag dauern...
;D
Habe heute einen Shellydimmer bekommen und überlegt, wie ich ihn am Besten in fhem einbinde.
Da ich schon einige Tasmota-Geräte mit MQTT eingebunden habe, war das für mich die erste Wahl.
Und wie ich hier sehe, auch die beste.
Bis auf mein Unvermögen, die passenden Templates auf Anhieb in die Auswahl zu bringen, kann ich nur sagen: MQTT ist echt Klasse!
Hat auch den Vorteil, dass der Status beim Schalten am Dimmer sofort an fhem übertragen wird.
Der Charme vom Shelly_Modul ist, dass es mit dem Shelly-Cloud-Betrieb vereinbar ist und obendrein noch simpler je Device ist. Bei MQTT mit Shellys werden jede Menge Readings erzeugt, die man erst einmal mit den "event-..."-Attributen zusammendampfen muss.
@pah: Mir ist erst neulich aufgefallen, wie geschwätzig die Shellys auch beim "Multicasten" mit ihrem "Hausprotokoll "CoIoT" sind. Darüber *könnte* man eventuell ja das Pollen ganz vermeiden und ggf. sogar noch ein "AutoCreate" on top legen. Ich habe aber nicht geprüft, inwieweit die "interessanten" Attribute (Schaltzustand, Verbrauch, etc.) beinhaltet sind.
Zitat von: micky0867 am 30 Dezember 2020, 18:25:36
;D
Habe heute einen Shellydimmer bekommen und überlegt, wie ich ihn am Besten in fhem einbinde.
Da ich schon einige Tasmota-Geräte mit MQTT eingebunden habe, war das für mich die erste Wahl.
Und wie ich hier sehe, auch die beste.
Bis auf mein Unvermögen, die passenden Templates auf Anhieb in die Auswahl zu bringen, kann ich nur sagen: MQTT ist echt Klasse!
Hat auch den Vorteil, dass der Status beim Schalten am Dimmer sofort an fhem übertragen wird.
...merkwürdig, seit PAH den Dimmer in das Modul integriert hat, funktioniert das doch outofthebox einwandfrei, ohne Kenntnisse von MQTT und irgendwelchen Templates ! und mit WidetOverride konnte ich dank dem Tip von PAH auch noch einen Slider realisieren. Wunschlos glücklich würde ich meinen
@cs-online: micky0867 nutzt ja auch (extra ;) ) nicht das Modul...
Und meint das sei die bessere Wahl gewesen...
@micky0867: man kann auch mit dem Modul sofort den Schaltzustand bekommen (soweit ich weiß)...
Gruß, Joachim
Zitat von: Peteruser am 30 Dezember 2020, 17:06:27
Dann aus meiner Ecke danke dafür ;D
Schon mal auf den Gedanken gekommen, dass hostname eventuell kontraproduktiv ist?
pah _könnte_ ja nicht nur (ob des auch m.E. unverschämten Tonfalls des Wünschenden) aus nachvollziehbaren emotionalen Gründen klare Kante gezeigt haben ;) . Man könnte auch einfach grundsätzlich mal unterstellen, dass er gute technische Gründe hat, bestimmte Komfortfunktionen NICHT zu nutzen...
Und ist doch schön, dass man die Wahl zwischen verschiedenen Optionen hat :) .
Anleitung für @micky0867: Einfach mal den allerersten Post in diesem Thread lesen, dann den eigenen Post löschen, sich weiterer Bemerkungen enthalten und hier verschwinden.
@gvzdus: Die Geschwätzigkeit der Shellys ist schon bekannt - sie hat beispielsweise dafür gesorgt, dass die BOSE SoundTouch App, die einen internen Fehler hatte, über Monate hinweg innerhalb von Sekunden abstürzte. Und da BOSE als US-Hersteller notorisch lahmarschig beim Update der Software für den europäischen Markt ist, ging das dann nur unter Umwegen.
Betreffend ColoT allerdings: Erstens ist das Schalten von Aktoren damit nicht möglich - eigentlich ist das also nur für Sensoren gedacht. Und zweitens kenne ich keine brauchbare Dokumentation des Protokolls, die paar Seiten von Allterco sind sehr dürftig.
@cs-online, Madmax-FHEM und Beta-User: Genau so wars gedacht und ist auch im "SmartHome mit FHEM" so publiziert: Einfach, und Out-of-the-Box. Ich nutze MQTT an vielen Stellen, baue gerade neue Raumluftsensoren auf MQTT-Basis zusammen - aber meine Shelly-Rollladenaktoren und diverse Shelly-Switches laufen alle mit
diesem Modul hier. Ich finde es immer wieder erstaunlich, wie viele sich begeistert über MQTT äußern, wenn sie nur endlich dessen erste Grundlagen verstanden haben. Bei genauerem Verständnis ist MQTT nämlich für viele Zwecke einfach Overkill.
Eine "sofortige" Kenntnis des Schaltzustands eines Shelly erfordert lediglich, dass in die Shelly-Konfiguration unter "Actions" der passende Eintrag für "Button Press URL" oder "Roller Open/Close/Stop URL" erfolgt, also z.B.
Zitathttp://192.168.0.XX:8083/fhem?XHR=1&cmd=get%20BI.F.Roll%20status
(ggf. zuzüglich csrf-Token und Passwort).
Im Übrigen unterstützt die jüngste Version des Moduls auch den Shelly-EM. Die Shelly-Bulbs sind prinzipiell ebenfalls nutzbar - allerdings kann ich das mangels Hardware nicht testen, und eine Programmerweiterung nur auf Basis einer API-Dokumentation ist ziemlich aufwändig.
Letzte Bemerkung: Shelly Sense, das ist das Teil zur Ansteuerung von IR-fernbedienbaren Geräten, hat auch Potenzial. Allerdings wäre hier für eine komfortable und einfache Nutzung der Zugriff auf die Shelly-Cloud nötig, sonst muss man jeden IR-Code von Hand herausfinden.
LG
pah
Zitat von: MadMax-FHEM am 30 Dezember 2020, 19:29:31
Und meint das sei die bessere Wahl gewesen...
Bei dem Tonfall, den hier bestimmte , scheinbar unfehlbare, Personen an den Tag legen, glaube ich das schon.
Zitat von: MadMax-FHEM am 30 Dezember 2020, 19:29:31
@micky0867: man kann auch mit dem Modul sofort den Schaltzustand bekommen (soweit ich weiß)...
Ja, das stimmt, allerdings finde ich es eher unpraktisch, wenn ich auf dem Gerät neben der IP von fhem auch noch den Namen des Gerätes und, noch aufwändiger,
Zitat(ggf. zuzüglich csrf-Token und Passwort)
hinterlegen muss.
Bei MQTT habe ich "nur" die IP des Servers eingetragen und das richtige Template gewählt. Das war's.
MQTT hat bei mir kein Passwort.
Aber es ist müßig, darüber zu diskutieren.
Wenn man mal beide Wege ausprobiert hat, kann man sich ja selbst entscheiden.
Ich wollte eigentlich nur die Kritiker auf die andere Möglichkeit hinweisen, damit sie hier, so wie ich jetzt, und von pah unmissverständlich erwünscht, endlich verschwinden.
Jetzt gibt es immerhin schon 2 Mitglieder, denen ich aus dem Weg gehen werde.
@micky0867
Wenn jemand lieber MQTT nutzt, ist das ja prima.
Aber dann sollte man nicht im Thread für das Shelly-Modul rumposaunen.
Für MQTT/Shelly gibt's eigene Threads.
Betreffend ColoT allerdings: Erstens ist das Schalten von Aktoren damit nicht möglich - eigentlich ist das also nur für Sensoren gedacht. Und zweitens kenne ich keine brauchbare Dokumentation des Protokolls, die paar Seiten von Allterco sind sehr dürftig.
Ich habe mal gebastelt, siehe im Nachbarthread "Kleiner Shelly-CoIoT-Sniffer".
Ja, richtig hübsch ist das nicht. Aber es würde z.B. für die Shellys, die ich zur Leistungsmessung einsetze, eine Alternative zum Pollen oder MQTT sein. Da greift ja der "Button-URL-Trick" nicht.
https://forum.fhem.de/index.php/topic,117243.0.html (https://forum.fhem.de/index.php/topic,117243.0.html)
Hallo Leute,
ich habe für mich auch die coolen Shelly Devices entdeckt. Habe bis jetzt einen Switch und zwei Plugs im Einsatz. Das Einzige was auf allen Geräten nicht funktioniert ist on-for-timer und off-for-timer. Es wird jeweils ein aber nicht aus, bzw. sofort ausgeschaltet. Gibt es da einen Trick?
@Prostetnik: Wundert mich, das ist eigentlich ordentlich implementiert. Gibt es irgendwas dazu im Log?
LG
pah
Mit Verbose=5:
2021.01.01 08:21:31 5 : [Shelly_onoff] Issue a non-blocking call to http://192.168.123.52/relay/0?turn=on&timer=10
2021-01-01 08:21:31 Shelly Sh_Plug2 on-for-timer 10
2021.01.01 08:21:32 5 : [Shelly_onoff] has obtained data {"ison":true,"has_timer":true,"timer_started":1609489292,"timer_duration":10,"timer_remaining":10,"overpower":false,"source":"http"}
2021-01-01 08:21:32 Shelly Sh_Plug2 on
2021-01-01 08:21:32 Shelly Sh_Plug2 relay: on
2021-01-01 08:21:32 Shelly Sh_Plug2 overpower: 0
2021.01.01 08:21:32 5 : [Shelly_onoff] Issue a non-blocking call to http://192.168.123.52/relay/0?turn=on
2021-01-01 08:21:32 Shelly Sh_Plug2 on 1
2021.01.01 08:21:32 5 : [Shelly_onoff] has obtained data {"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"source":"http"}
2021-01-01 08:21:32 Shelly Sh_Plug2 relay: on
2021-01-01 08:21:32 Shelly Sh_Plug2 overpower: 0
2021.01.01 08:21:32 5 : [Shelly_onoff] Issue a non-blocking call to http://192.168.123.52/relay/0?turn=on
2021-01-01 08:21:32 Shelly Sh_Plug2 on 1
2021.01.01 08:21:32 5 : [Shelly_onoff] has obtained data {"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"source":"http"}
2021-01-01 08:21:32 Shelly Sh_Plug2 relay: on
2021-01-01 08:21:32 Shelly Sh_Plug2 overpower: 0
2021.01.01 08:21:33 5 : [Shelly_status] Issue a non-blocking call to http://192.168.123.52/status
2021.01.01 08:21:33 5 : [Shelly_status] Issue a non-blocking call to http://192.168.123.52/status
2021.01.01 08:21:33 5 : [Shelly_status] Issue a non-blocking call to http://192.168.123.52/status
2021.01.01 08:21:33 5 : [Shelly_status] has obtained data {"wifi_sta":{"connected":true,"ssid":"StevesWirelessNetwork_FB","ip":"192.168.123.52","rssi":-52},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":false},"time":"08:21","unixtime":1609485693,"serial":3043,"has_update":false,"mac":"F4CFA26CBF31","cfg_changed_cnt":0,"actions_stats":{"skipped":0},"relays":[{"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"source":"http"}],"meters":[{"power":0.00,"overpower":0.00,"is_valid":true,"timestamp":1609489293,"counters":[0.000, 0.000, 0.000],"total":29260}],"update":{"status":"idle","has_update":false,"new_version":"20201228-092942/v1.9.3@ad2bb4e3","old_version":"20201228-092942/v1.9.3@ad2bb4e3","beta_version":"20201202-141133/v1.9.3-rc3@50c6ab57"},"ram_total":51056,"ram_free":36000,"fs_size":233681,"fs_free":160389,"uptime":140236}
2021.01.01 08:21:33 5 : [Shelly_status] has obtained data {"wifi_sta":{"connected":true,"ssid":"StevesWirelessNetwork_FB","ip":"192.168.123.52","rssi":-52},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":false},"time":"08:21","unixtime":1609485693,"serial":3043,"has_update":false,"mac":"F4CFA26CBF31","cfg_changed_cnt":0,"actions_stats":{"skipped":0},"relays":[{"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"source":"http"}],"meters":[{"power":0.00,"overpower":0.00,"is_valid":true,"timestamp":1609489293,"counters":[0.000, 0.000, 0.000],"total":29260}],"update":{"status":"idle","has_update":false,"new_version":"20201228-092942/v1.9.3@ad2bb4e3","old_version":"20201228-092942/v1.9.3@ad2bb4e3","beta_version":"20201202-141133/v1.9.3-rc3@50c6ab57"},"ram_total":51056,"ram_free":36796,"fs_size":233681,"fs_free":160389,"uptime":140236}
2021.01.01 08:21:33 5 : [Shelly_status] has obtained data {"wifi_sta":{"connected":true,"ssid":"StevesWirelessNetwork_FB","ip":"192.168.123.52","rssi":-52},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":false},"time":"08:21","unixtime":1609485693,"serial":3043,"has_update":false,"mac":"F4CFA26CBF31","cfg_changed_cnt":0,"actions_stats":{"skipped":0},"relays":[{"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"source":"http"}],"meters":[{"power":0.00,"overpower":0.00,"is_valid":true,"timestamp":1609489293,"counters":[0.000, 0.000, 0.000],"total":29260}],"update":{"status":"idle","has_update":false,"new_version":"20201228-092942/v1.9.3@ad2bb4e3","old_version":"20201228-092942/v1.9.3@ad2bb4e3","beta_version":"20201202-141133/v1.9.3-rc3@50c6ab57"},"ram_total":51056,"ram_free":37600,"fs_size":233681,"fs_free":160389,"uptime":140236}
.
.
.
.
.
.
[das Folgende wiederholt sich dann alle 60s]
2021.01.01 08:22:33 5 : [Shelly_status] Issue a non-blocking call to http://192.168.123.52/status
2021.01.01 08:22:33 5 : [Shelly_status] has obtained data {"wifi_sta":{"connected":true,"ssid":"StevesWirelessNetwork_FB","ip":"192.168.123.52","rssi":-52},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":false},"time":"08:22","unixtime":1609485753,"serial":3045,"has_update":false,"mac":"F4CFA26CBF31","cfg_changed_cnt":0,"actions_stats":{"skipped":0},"relays":[{"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"source":"http"}],"meters":[{"power":95.49,"overpower":0.00,"is_valid":true,"timestamp":1609489353,"counters":[85.568, 0.000, 0.000],"total":29346}],"update":{"status":"idle","has_update":false,"new_version":"20201228-092942/v1.9.3@ad2bb4e3","old_version":"20201228-092942/v1.9.3@ad2bb4e3","beta_version":"20201202-141133/v1.9.3-rc3@50c6ab57"},"ram_total":51056,"ram_free":39280,"fs_size":233681,"fs_free":160389,"uptime":140296}
Der erste on-for-timer-Befehl wird richtig übermittelt und erkannt. Woher kommt in derselben Sekunde der on-Befehl? Das Modul setzt so etwas nicht von alleine ab.
Kann es sein, dass in dem Action-Feld im Shelly ein falscher Eintrag ist ?
LG
pah
Hmm. Ich habe natürlich die URL's gesetzt, damit ich die Schaltzustände in FHEM erfasse:
Url to be hit when the output is switched ON
http://192.168.123.81:8083/fhem?XHR=1&cmd=set%20Sh_Plug2%20on%201
Url to be hit when the output is switched OFF
http://192.168.123.81:8083/fhem?XHR=1&cmd=set%20Sh_Plug2%20off%201
Ok, ich denke ich hab's verstanden. Aber wie kriege ich dann die Info, wenn man die Teile manuell ein- oder ausschaltet?
ZitatAber wie kriege ich dann die Info, wenn man die Teile manuell ein- oder ausschaltet?
An beiden Stellen:
http://192.168.123.81:8083/fhem?XHR=1&cmd=get%20Sh_Plug2%20statusDann holt FHEM sich den neuen Status.
Verstehe ich das richtig, Taster am Shelly drücken , der sagt "FHEM frag mich mal nach meinem neuen Status" , FHEM "shelly status ?" , Shelly "on"
Muss man das Ping-Pong Spiel wirklich spielen oder kann nicht gleich im Shelly ein setreading shelly on/off absetzen ?
Für einen Plug geht das sicher auch. Ich nutze das für einen Dimmer - da wird dann auch die Dimmstufe abgeholt. Auf die hat man mit der URL keinen Zugriff.
Mein erster Wurf des CoIoT-Moduls ist jetzt fertig, siehe hier: https://forum.fhem.de/index.php/topic,117309.0.html (https://forum.fhem.de/index.php/topic,117309.0.html)
Ich bitte um Gnade im Falle des FHEM-Crashes, aber ich denke, dem Einen oder Anderen könnte es gefallen.
Zitat von: JWRu am 01 Januar 2021, 13:32:20
An beiden Stellen:
http://192.168.123.81:8083/fhem?XHR=1&cmd=get%20Sh_Plug2%20status
Dann holt FHEM sich den neuen Status.
Funktioniert! Danke!
Hallo,
ich habe immer mal wieder Error-Meldungen bei einzelnen Shelly-Devices und kann nicht erkennen, woran es liegt oder wie ich es beheben kann.
Hier mal ein aktuelles list:
Internals:
DEF 192.168.178.161
DURATION 0
FUUID 5fdc9c0a-f33f-8efe-0f71-658fc6f4046bf28b
INTERVAL 15
NAME Kueche_rechts
NR 3015
STATE Error
TCPIP 192.168.178.161
TYPE Shelly
READINGS:
2020-12-18 13:09:48 cloud disabled
2021-01-02 19:44:54 firmware v1.9.0
2021-01-05 12:13:42 network not connected
2020-12-23 09:59:12 relay off
2021-01-05 12:13:42 state Error
Attributes:
group group EG,Kueche
icon scene_dinner
interval 15
model shelly1
room 1.Start,Shelly
sortby 964
userattr LichtAlarm LichtAlarm_map structexclude
webCmd :
Das Gerät ist über die IP-Adresse im Web ganz normal erreich- und steuerbar. Kein Fehler -für mich- erkennbar.
Ich kann es aber über FHEM nicht steuern und bekomme auch kein Status-Anzeigen in FHEM.
Über
get Kueche_rechts status
erhalte ich
Kueche_rechts status => ok.
Im Logfile des letzten Kontaktages finde ich folgendes:
2021.01.02 05:58:05 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
Die Software des Shelly ist aktuell.
In der Regel ist es manchmal -aber nicht immer- so, dass ein reboot des Shelly wieder alles auf normal setzt.
Wenn das nicht hilft, muss FHEM über shutdown restart neu gestartet werden.
Danach ist alles wieder normal, bis zum nächsten Error in ein paar Tagen oder Wochen.
list sieht dann -nach shutdown restart- so aus:
Internals:
DEF 192.168.178.161
DURATION 0
FUUID 5fdc9c0a-f33f-8efe-0f71-658fc6f4046bf28b
INTERVAL 15
NAME Kueche_rechts
NR 3011
STATE off
TCPIP 192.168.178.161
TYPE Shelly
READINGS:
2020-12-18 13:09:48 cloud disabled
2021-01-05 12:53:06 firmware v1.9.3
2021-01-05 12:52:43 network <html>connected to <a href="http://192.168.178.161">192.168.178.161</a></html>
2020-12-23 09:59:12 relay off
2021-01-05 12:53:06 state off
Attributes:
group group EG,Kueche
icon scene_dinner
interval 15
model shelly1
room 1.Start,Shelly
sortby 964
userattr LichtAlarm LichtAlarm_map structexclude
webCmd :
Hat jemand eine Idee dazu?
ZitatIm Logfile des letzten Kontaktages finde ich folgendes:
2021.01.02 05:58:05 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
Hast Du das nur einmal, oder mehrmals nacheinander?
Zitat von: amenomade am 05 Januar 2021, 13:19:04
Hast Du das nur einmal, oder mehrmals nacheinander?
Jep, siehe auch dort: https://forum.fhem.de/index.php/topic,117169.msg1115400.html#msg1115400
Wenn nur 1x (oder sehr ab und an) dann ist halt das Modul zu "ungeduldig" (ohne jetzt als "Beschwerde" verstanden zu werden ;) ) gegenüber einem Browser, der schon mal länger versucht, ob nicht doch was zu laden ist.
Daher kannst du (evtl.) mit dem Browser nichts feststellen und denkst: IMMER alles ok. (aber vielleicht manchmal nicht ganz so ok ;) )...
Wenn öfter/häufig: dann mal bzgl. Netzwerk prüfen (und noch mal: ein Browser ist sicher "geduldiger" ;) )...
Gruß, Joachim
Ich habe das auch ab und zu - ist kein Problem.
Zitat von: amenomade am 05 Januar 2021, 13:19:04
Hast Du das nur einmal, oder mehrmals nacheinander?
Ich habe das schon häufiger im log:
2021.01.02 19:47:29 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:47:48 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:48:08 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:48:27 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:48:47 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:49:06 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:49:15 3: sduino IT_set: Garage_Vorne off
2021.01.02 19:49:16 3: sduino433Mhz IT: Kueche_3 off->off
2021.01.02 19:49:16 3: sduino433Mhz IT: Garage_Vorne off->off
2021.01.02 19:49:25 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:49:45 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:50:04 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:50:23 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:50:43 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:51:02 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:51:21 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:51:41 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:51:48 3: CUL_HM set Warmwasserpumpe off noArg
2021.01.02 19:52:00 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:52:20 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:52:39 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:52:58 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:53:18 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:53:23 3: CUL_HM set Deckenlampe_Flur off noArg
2021.01.02 19:53:37 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:53:56 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:54:15 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:54:35 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:54:54 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:54:58 3: LED_Kueche: EspLedController_RGB2HSV: 429.258823529412 - 76.2235294117647 - 393.152941176471
2021.01.02 19:55:13 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:55:32 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:55:52 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:56:11 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:56:30 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:56:37 3: LED_Kueche: EspLedController_RGB2HSV: 1023 - 1023 - 1023
2021.01.02 19:56:50 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:57:09 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:57:28 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:57:48 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:58:07 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:58:27 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:58:46 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:59:05 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:59:25 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed out
2021.01.02 19:59:44 1: [Shelly_status] has error connect to http://192.168.178.161:80 timed outZum Netzwerk:
Ich habe ein Unify Netzwerk. Normalerweise habe ich damit kein Probleme.
Signal am Shelly: WiFi RSSI: -67 dBm
Das ist ein Netzwerkproblem der Shelly seit Firmware 1.8.
Timeout hochsetzen.
LG
pah
Hallo PAH,
wie mach ich das ? Ich find da kein Attribut, was ähnlich lauten würde
Grüße
Christian
Versuchs mal mit der angehängten Beta-Version. Da ist das als Attribut eingebaut. Beginne mit 5 Sekunden, langsam hochsetzen.
LG
pah
Guten Morgen,
Ich nutze das Modul seit kurzem. Vielen Dank dafür! :)
/edit
Problem bereits gelöst, Link im Code Container funktioniert :)
http://username:passwort@192.168.178.36:8083/fhem?XHR=1&cmd=get%20BAD_OG.Spots%20status
Username und Passwort wie für FHEM vergeben.
ZitatSollte das stattdessen eingetragen werden?
Aber das steht doch oben drin?
Verstehe die Frage nicht.
LG
pah
Zitat von: Xell1984 am 06 Januar 2021, 11:03:17
http://username:passwort@192.168.178.36:8083/fhem?XHR=1&cmd=get%20BAD_OG.Spots%20status
Also, bei username:passwort gehört wohl selbstverständlich dein FHEM-Username und dein FHEM-PW rein. Die IP natürlich auf die IP deines FHEM-Servers anpassen, das was da als BAD_OG.Spots drin steht, muss ebenfalls auf den Devicenamen des Shellys angepasst werden, dessen Status du setzen lassen willst, sprich, den du schaltest.
Hilft das ?
Grüße Christian
Zitat von: Prof. Dr. Peter Henning am 06 Januar 2021, 07:09:28
Versuchs mal mit der angehängten Beta-Version. Da ist das als Attribut eingebaut. Beginne mit 5 Sekunden, langsam hochsetzen.
LG
pah
Danke, hab ich mal eingespielt und werde berichten,
Grüße
Christian
habe die Beta mal installiert und bin mittlerweile bei 20sec und keine Änderung.
der Shelly 1 läuft ohne Probleme.
Internals:
DEF 192.168.178.96
FUUID 5ff8292b-f33f-395a-9245-145b7e82bb888f41
INTERVAL 0
NAME RGWB2
NR 972
SHELLYID shellyrgbw2-AFAD1A
STATE Error
TCPIP 192.168.178.96
TYPE Shelly
READINGS:
2021-01-08 10:43:53 cloud disabled
2021-01-08 10:43:53 firmware v1.9.3-rc3(update needed to v1.9.0)
2021-01-08 11:00:37 network connected to 192.168.178.96
2021-01-08 11:00:46 state Error
Attributes:
interval 0
model shellyrgbw
room 9.90 Helper->MQTT
shellyuser Dirk
timeout 20
Kann es daran liegen, das ich den Shelly als 4ch. White Schalter benutze?
Noch ein Update:
was mir im startLog auffällt:
2021.01.08 11:00:46.323 1: [Shelly_status] invalid JSON data
2021.01.08 11:00:46.407 1: [Shelly_configure] has invalid JSON data
2021.01.08 11:00:46.417 1: [Shelly_configure] has invalid JSON data
2021.01.08 11:00:46.851 1: [Shelly_status] invalid JSON data
Ich verstehe nicht, was dieser angebliche Fehler mit dem Timeout zu tun haben sollte, den ich für Christian eingestellt habe.
LG
pah
Hallo PAH,
soweit ich das in der Kürze erkennen kann, sieht das schon sehr gut aus. Ich beobachte weiter :-)
Grüße
Christian
Hallo,
ich habe 2 Shelly DUO GU10 gestern installiert. Werden die von dem shelly Modul schon "unterstützt"?
Wenn als Modell "shellydimmer" auswähle, kann ich das Gerät ein- & ausschalten und zumindest auch die Helligkeit im Reading PCT auslesen. Was ich nicht sehe, ist die Farbtemperatur.
mit dem CoIoT modul habe ich die Multicasts der beiden DUOs mitprotokolliert (falls das irgendwie hilft):
2021.01.08 21:49:45 5: Received data from 192.168.178.247
2021.01.08 21:49:45 5: 192.168.178.247: in cache: shelly_generic_shbduo_1_483fda6fcc79
2021.01.08 21:49:45 5: URI: /cit/s, global_devid = SHBDUO-1#483FDA6FCC79#2, validity=3840, serial=345
2021.01.08 21:49:45 5: Found device shelly_generic_shbduo_1_483fda6fcc79, model shellydimmer
2021.01.08 21:49:45 5: cfgChanged = 1
2021.01.08 21:49:45 5: output_0 = 0
2021.01.08 21:49:45 5: brightness_0 = 50
2021.01.08 21:49:45 5: colorTemp = 4220
2021.01.08 21:49:45 5: whiteLevel = 40
2021.01.08 21:49:45 5: power_0 = 0
2021.01.08 21:49:45 5: energy_0 = 251
2021.01.08 21:49:45 5: Received data from 192.168.178.243
2021.01.08 21:49:45 5: 192.168.178.243: in cache: shelly_generic_shbduo_1_483fda6ffd3c
2021.01.08 21:49:45 5: URI: /cit/s, global_devid = SHBDUO-1#483FDA6FFD3C#2, validity=3840, serial=622
2021.01.08 21:49:45 5: Found device shelly_generic_shbduo_1_483fda6ffd3c, model shellyid
2021.01.08 21:49:45 5: cfgChanged = 8
2021.01.08 21:49:45 5: output_0 = 0
2021.01.08 21:49:45 5: brightness_0 = 50
2021.01.08 21:49:45 5: colorTemp = 4220
2021.01.08 21:49:45 5: whiteLevel = 40
2021.01.08 21:49:45 5: power_0 = 0
2021.01.08 21:49:45 5: energy_0 = 300
Viele Grüße,
Tim
CommandRef lesen.
LG
pah
Hallo Prof. Dr.,
danke für die schnelle Rückmeldung. Wo genau in der CommandRef finde ich die GU10 erwähnt oder deren Readings oder wie ich dieses Device mit dem Modul "sinnvoll" einrichten kann? Ich habe den Text mehrfach gelesen und auch (trotz nicht vorhandener Programmier-Erfahrung) weitesgehend verstanden - aber auf dem Auge scheine ich völlig blind zu sein. Ich kann aus der CommandRef keinerlei Rückschlüsse auf das korrekte Einbinden der DUO GU10 ziehen - und die Suche hat mich auch (noch) nicht weiter gebracht, denn sonst hätte ich a) mich nicht angemeldet um b) die Frage zu stellen.
Vielen Dank nochmal & viele Grüße,
Tim
Moin, ich glaube, das sieht nicht wirklich gut mit "out of the box" aus:
- Farbtemperatur im White-Modus ist kein Merkmal von rgbw oder dimmer
- Mein veralteter Shelly-Bulb verhält sich im Farbmodus auch anders als model rgbw / mode color
ZitatMein veralteter Shelly-Bulb verhält sich im Farbmodus auch anders als model rgbw / mode color
Jein. So anders ist es gar nicht: Das Problem entsteht, wenn man die direkte Web-GUI des Bulb und die Shelly-Steuerung gemischt benutzt. Shelly steuert die Helligkeit im Farbmodus über "gain", während die Mischung der Farbkanäle "auf Vollausschlag" passiert. Wenn ich das Set-Kommando um ein "&gain=100" ergänze, und das Auslesen um eine Multiplikation der rgb-Werte mit "gain / 100", dann harmonieren Web-GUI und Shelly-Modul nach erster Beobachtung. "gain" ist allerdings zumindest für den Shelly RGBW2 dokumentiert:
https://shelly-api-docs.shelly.cloud/#shelly-rgbw2-color-color-0 (https://shelly-api-docs.shelly.cloud/#shelly-rgbw2-color-color-0)
Ob Vorgänger "gain" nicht kannten, weiß ich nicht. Und auch nicht, ob sich meine Beobachtung "funktioniert im Prinzip, bis auf 'gain'" auf die Shelly-Duos mit Farbe ausweiten lässt.
Zum White-Modus untersuche ich mal als Nächstes.
Das Problem ist nicht, irgendwelche neuen API-Parameter in das Modul einzubauen. Sondern, dass ich nicht jede Sorte von Shelly-Hardware kaufen werde und auch kein Auftragsprogrammierer bin. Wenn jemand also eine spezielle Sorte Hardware besitzt, sollte er an Hand der API-Dokumentation selbst herausfinden, was wo eingestellt werden kann (/settings bzw. /status). Dann kann ich das gerne einbauen.
LG
pah
So, wegen des RGBW2
2021.01.10 09:41:50.603 1: [Shelly_status] has error http://Dirk:@192.168.178.96/status: malformed or unsupported URL
Gruss Dirk
Zitatmalformed or unsupported URL
::)
Na, dann würde ich das doch erst einmal ohne Passwort und Username probieren - dann wird auch schnell klar, wo der Fehler liegt. Mehr sage ich dazu nicht, dafür ist mir meine Lebenszeit wirklich zu schade.
pah
Zitat von: hyper2910 am 10 Januar 2021, 09:46:18
So, wegen des RGBW2
2021.01.10 09:41:50.603 1: [Shelly_status] has error http://Dirk:@192.168.178.96/status: malformed or unsupported URL
Gruss Dirk
...hast du den Shelly selber denn PW-geschützt ?
ja
Zitat von: cs-online am 10 Januar 2021, 10:42:51
...hast du den Shelly selber denn PW-geschützt ?
ja habe ich, genau wie den SHelly1 auch.
Das PW im Modul ist richtig gesetzt und auch ohne PW, das gleiche Problem.
Gerät in FHEM "Initialized" und nach ein 10-20sec Error.
Egal, ich steuer die Dinger über MQTT, da mir meine Lebenszeit auch zu schade ist mit einem Prof zu diskutieren!
Mit bockig kommt man hier nicht weiter. Also, man kann natürlich über Sinn und Unsinn von vom (hoffentlich mit PW geschützten) WLAN und darin befindlichen (nochmal PW-geschützten) Devices sprechen, aber ich würde einfach mal im Shelly das PW raus nehmen, den dann neu starten, dann mittels Modul ansprechen, dann muss das (wie bei allen anderen auch) auch funktionieren, wenn nicht, liegt das nicht am Modul....
Grüße
Christian
Mit oder ohne pw, das gleiche.
Ich denkendes Modul unterstützt nicht die Shelly als 4channel
2021.01.10 09:41:50.603 1: [Shelly_status] has error http://Dirk:@192.168.178.96/status: malformed or unsupported URL
heisst: er hat ein User (Dirk) gefunden, aber kein Passwort.
Das seitens Fhem gesetzte Passwort kannst Du in /opt/fhem/FHEM/FhemUtils/uniqueID nachsehen.
SHELLY_PASSWORD_shellyrgbw2-AFAD1A:hierDasPasswort
Wenn da nix sichtbar ist (oder der Name oder das Passwort nicht stimmt), wurde das Passwort nicht ordentlich gesetzt.
Wenn Du jetzt seitens Shelly User und Passwort löschst, muss Du die natürlich auch in Fhem löschen. Guck mal dann in der Log, was er für eine Url aufruft.
das ist alles gemacht.
Mit PW ohne PW.
Das Gerät war am Anfang mal für 10sec verbunden und danach nicht mehr.
Aber ich steuer das ganze mit MQTT!
http://Dirk:@192.168.178.96/status:...
Muss da nicht der Doppelpunkt hinter Dirk weg?
ZitatAber ich steuer das ganze mit MQTT!
Es ist immer nett, wenn Herzenswünsche in Erfüllung gehen.
pah
hallo PAH,
Könntest du für die Shelly1/Shelly1PM mit AddOn im Modul noch die ext_temperature_0_tC auslesen?
Man bekommt es zwar auch mit einem UserReading hin, aber mit Modul wäre es einfacher, vorallem wenn man viele Shellys verwendet.
Das werde ich auf die Schnelle nicht tun, sondern erst selbst einmal testen. Da gibt es nämlich unterschiedliche Einheiten zu berücksichtigen, außerdem kann auch die Feuchte gemessen werden.
LG
pah
Ich habe eine neue Version des Moduls eingecheckt.
- Support für Shelly Bulb/Shelly Duo (noch etwas frickelig, da ich das nicht selbst getestet habe)
- Timeout für langsame Netzverbindungen einstellbar
- Zusammenarbeit mit dem neuen Modul 36_ShellyMonitor.pm. Das fängt die Multicast-Nachrichten der Shellys ab, ein Pollen ist damit nicht mehr nötig und die Shelly-Devices werden automatisch erkannt und angelegt.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 16 Januar 2021, 10:30:40
Das werde ich auf die Schnelle nicht tun, sondern erst selbst einmal testen. Da gibt es nämlich unterschiedliche Einheiten zu berücksichtigen, außerdem kann auch die Feuchte gemessen werden.
LG
pah
Welche Einheiten meinst du?
Mit dem DHT22 (Temperatur und Feuchte) gibt es 6 Readings. Anlage
Bei dem DS18B20 ( Temperatur; Max 3 Stk möglich) fehlen die Readings ext_humidity_0_hum und
ext_humidity_0_hwID und es kommen eventuell noch die Readings ext_temperature_1_ ... und ext_temperature_2 ... hinzu.
...ich mag mich ja täuschen, aber ein DS18B20 ist ein Temperatursensor, der hat keine Luftfeuchte (humidity)... , warum sollte es dann solche Readings geben ?
Grüße
Christian
Hallo PAH,
etwas merkwürdiges ist grad bei mir passiert, ich weiß nicht, ob das am ShellyMonitor-Modul oder am FHEM liegt, denn die fhem.pl ist auch upgedatet worden. Ich lege das Device an:
define ShellyMonitor ShellyMonitor
Dann wird das Device erzeugt und angezeigt. Es finden sich auch schon bekannte shellys, bei save config kommt das Fragezeichen, oben im Reiter dreht und dreht es sich. Dann einen kurzen Moment später ist die Seite blank, das Fragezeichen bei save config ist weg und wenn ich dann ein list ShellyMonitor absetze, sagt er, es gäbe kein solches Device... also neu angelegt, und so weiter, immer im Kreis...
Wenn ich einen Dummy anlege, passiert sowas nicht...
Hast du eine Idee ?
Grüße
Christian
Vermutlich besser dort fragen: https://forum.fhem.de/index.php/topic,117309.msg1116852.html#msg1116852
Oder da: https://forum.fhem.de/index.php/topic,117805.0.html
Gruß, Joachim
Hallo Joachim,
danke für den Hinweis, ich bin automatisch davon ausgegangen, dass das neue Modul von PAH ist... Habe mein Problem jetzt hier gepostet:
https://forum.fhem.de/index.php/topic,117805.0.html (https://forum.fhem.de/index.php/topic,117805.0.html)
Grüße
Christian
Zitat von: cs-online am 17 Januar 2021, 11:15:52
...ich mag mich ja täuschen, aber ein DS18B20 ist ein Temperatursensor, der hat keine Luftfeuchte (humidity)... , warum sollte es dann solche Readings geben ?
Grüße
Christian
Steht eigentlich dort! beim DS18B20 fehlen die Luftfeuchtewerte.
...wozu sollten solche Readings da sein, wenn der Sensor das gar nicht hergibt ? Oder habe ich das einfach nur falsch verstanden ?
Das war eine Antwort darauf:
Zitat von: Prof. Dr. Peter Henning am 16 Januar 2021, 10:30:40
Das werde ich auf die Schnelle nicht tun, sondern erst selbst einmal testen. Da gibt es nämlich unterschiedliche Einheiten zu berücksichtigen, außerdem kann auch die Feuchte gemessen werden.
LG
pah
Hallo, es gibt ja seit einiger Zeit den Shelly 1L (Shelly 1 ohne Nullleiter). Habe ihn als Device eingebaut und er wurde auch als shelly1l erkannt. Konnte ihn einige Tage schalten (einen DOIF mit on-for-Timer im Zusammenspiel mit einem Bewegungsmelder) und plötzlich ging nichts mehr (keine Reaktion über Schalter, App, Browser, fhem). Einstellungen Einstellungen Änderungen am Gerät waren jedoch möglich (App, Browser) Wollte vor einer tieferen Analyse und einer parallel laufenden Anfrage im Shelly Forum hier mal nachfragen, ob schon jemand (ähnliche) Erfahrung gemacht hat. Danke für Rückmeldung.
LG Peter
Mein Vorschlag wäre, FHEM upzudaten, also einmal oben "update" und danach "shutdown restart".
Es ist denkbar, dass FHEM schlichtweg wegen eines Bugs in ShellyMonitor abgestürzt ist und sehr schnell neu startete. Dieser Fehler ist inzwischen behoben.
Zum ShellyMonitor besser im ShellyMonitor-Thread ( https://forum.fhem.de/index.php/topic,117805.0.html ) fragen - ich bin der Autor und kriege nicht jeden neuen Thread mit.
Wenn ich das so lese, kann es ja nur am ShellyMonitor liegen.
Gute idee,mache ich auch.
LG
pah
Nach Anfrage im Shelly Forum hängt das Relais bei dem Shelly 1L bei zu großer Einschaltlast gerne mal. Ich habe zwar nur einen 200W Trafo dran, aber man kann wohl nicht ganz genau die Einschaltlast voraussagen. Ich hatte noch einen Zweiten und der läuft jetzt seit 2 Tagen ohne Probleme. Im Shelly Monitor habe ich ihn als Shelly1 deklariert und hier läuft die Kommunikation auch. Habe die Hoffnung, dass es so weitergeht.
Ich bin ja noch einer, der Handbücher liest und auch danach handelt und habe mit dem Leitfaden für FHEM angefangen und sogar Geld für ein Buch von pah ausgegeben. Aber ohne Forum hätte ich es nicht geschafft, soweit zu kommen. (Inkl. zufriedener Ehefrau). Wir (mein Sohn und ich) bewundern wirklich die ,,Leute", die sich mit einem solchen Enthusiasmus der Sache widmen und natürlich auch viel Zeit investieren (zum größten Teil ja auch neben dem Job).
Einen schönen Sonntag und Grüße aus dem verschneiten Köln Peter
Scherzhaft ist ja nett.
Das Problem ist aber, dass hier immer wieder Forumsteilnehmer glauben, sich zum Richter über andere Menschen aufschwingen zu können - und dann wird übel herumgestänkert, weil man sich ja anonym wähnt. Darum meine Nachfrage an der Stelle.
LG
pah
Hallo.
Ich habe seit der (mutmaßlichen) Änderung des Moduls vom 16.01.21 ein Problem mit 2 meiner 5 Shellys. Es handelt sich um 5 Shelly 1, die ganz normale Version ohne PM.
Diese melden Ihren state nicht mehr als ON/OFF, sondern nur noch als OK seit meinem FHEM-Update vom Freitag.
Spiele ich das 36_Shelly.pm aus einem Backup ein, welches ich davor in Nutzung hatte, melden die 2 betroffenen Aktoren sofort wieder Ihren Status mit ON bzw. OFF.
Hat es da Änderungen gegeben, welche mich zu lokalen Änderungen bei mir zwingen ? Oder ist da vielleicht ein Bug im Modul nach dem Update ?
Hallo,
das kann ich so nicht bestätigen, meine Shelly 1 ohne PM laufen nach wie vor unauffällig. Meine Datei ist lt. Eigenschaften vom 22.01.2021...
Grüße
Christian
Komisch. Firmware auf den Shelly's ist jeweils aktuell. Das fhem an sich ebenso.
Es sind auch nur 2/5 betroffen.
Crazy
Hallo zusammen, ich betreibe einen Shelly2.5 an einem Superrollo GW60. Da hier nur 24V zum Einsatz kommen, funktioniert dementsprechend die Kalibrierung des Shellys nicht (geht wohl nur mit 230V)
Besteht die möglichkeit ein Workaround mit dem Shelly Modul zu realisieren?
Möglicherweise funktioniert die automatische Kalibrierung nicht, weil die vom Rollladenmotor gezogene Leistung zu gering ist. An der Spannungsversorgung sollte es jedenfalls nicht liegen.
Wenn man sich die Settings direkt im device anschaut:
ZitatIP-Adresse/settings
gibt es unten bei
Zitatrollers/0
verschiedene Einstellungen für die Laufzeit: maxtime_open und maxtime_close sind auch über die Weboberfläche einstellbar. Das sind die beiden Werte, die bei der automatischen Kalibrierung ermittelt werden, mehr passiert dabei nicht. Die kann man also auch manuell eingeben (Achtung, in dem Fall auch das maxtime-Attribut im FHEM Device setzen).
Das setting off_power hingegen, das möglicherweise auch die Autokalibrierung ermöglicht, lässt sich nur durch einen REST-Befehl an das API einstellen, bitte die Dokumentation des API lesen. Wenn man weiß, wie die Synatx ist, kann man das auch über das Shelly-Modul absetzen.
LG
pah
Hallo,
Ich benutze ein paar Shelly 2.5 fuer die Rolladensteuerung.
Ich habe festgestellt, dass das die Werte des Readings stop_reason keine Aenderung aufgezeichnet haben.
Hat jemand das gleiche Problem?
Schoene Gruesse
Manos
Erstmal arbeiten wir hier im Forum nur sehr ungerne mit Screenshots, bitte beachten.
Zweitens: Wenn man das ändern will, muss man eben eine stop_reason herbeiführen, die nicht "normal" ist. Vielleicht einfach ein Hindernis in den Fahrweg des Rollladens setzen - ich übernehme aber keine Haftung für die Folgen.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 31 Januar 2021, 17:12:09
Erstmal arbeiten wir hier im Forum nur sehr ungerne mit Screenshots, bitte beachten.
Zweitens: Wenn man das ändern will, muss man eben eine stop_reason herbeiführen, die nicht "normal" ist. Vielleicht einfach ein Hindernis in den Fahrweg des Rollladens setzen - ich übernehme aber keine Haftung für die Folgen.
LG
pah
Vielen Dank fuer die Erklärungen. Ich werde mich mit den OBSTACLE DETECTION Variablen vertraut machen und es testen.
Noch eine Frage an alle Anwender: Hat jemand jemals einen
stop_reason Wert anderes als "normal" gesehen?
Schoene Gruesse
Manos
Meine Güte...
Das Update wird mit "readingsBulkUpdateIfChanged" aktualisiert. Jetzt verstanden?
LG
pah
Zitat von: Prof. Dr. Peter Henning am 31 Januar 2021, 22:15:07
Meine Güte...
Das Update wird mit "readingsBulkUpdateIfChanged" aktualisiert. Jetzt verstanden?
LG
pah
Neee, ueberhaupt nicht...
readingsBulkUpdate
$rv = readingsBulkUpdate($hash, $reading, $value);
$rv = readingsBulkUpdate($hash, $reading, $value, $changed);
Die Funktion readingsBulkUpdate() führt ein Update eines einzelnen Readings für die Definition $hash durch. Dabei wird das Readings $reading auf den Wert $value gesetzt. Bevor diese Funktion benutzt werden kann, muss readingsBeginUpdate() zuvor aufgerufen werden, ansonsten werden keine Updates durchgeführt.Was soll ich mit diesem Quatsch machen? Programmieren lernen weil niemand hier erklaeren kann, was stop_reason fuer eine Funktion hat?
Meine Güte...
ZitatWas soll ich mit diesem Quatsch machen? Programmieren lernen weil niemand hier erklaeren kann
Entweder das, oder sich abmelden und seinen Kram alleine machen. So einfach ist das.
Denn das ist keine Frage des "kann", sondern des "will" gegenüber ignoranten Benutzern.
pah
Zitatweil niemand hier erklaeren kann, was stop_reason fuer eine Funktion hat?
Einfach mal in der Shelly API nachschauen https://shelly-api-docs.shelly.cloud/_review/mqtt/#shelly-switch-relay-index (https://shelly-api-docs.shelly.cloud/_review/mqtt/#shelly-switch-relay-index)
Dort steht:
Zitatstop_reason bool Last cause for stopping: normal, safety_switch, obstacle
Das Reading wird nur aktualisiert, wenn sich der Wert ändert. Deshalb heißt die Funktion "...UpdateIfChanged".
Wenn es also wochenlang nur "normal" gab, ist die letzte Aktualisierung ewig her.
ZitatWenn es also wochenlang nur "normal" gab, ist die letzte Aktualisierung ewig her.
Richtig. Und warum?
LG
pah
Zitat von: Prof. Dr. Peter Henning am 31 Januar 2021, 08:45:43
Möglicherweise funktioniert die automatische Kalibrierung nicht, weil die vom Rollladenmotor gezogene Leistung zu gering ist. An der Spannungsversorgung sollte es jedenfalls nicht liegen.
Grad nochmal im Shelly Forum nachgeforscht. Wenn der Shelly mit 24V DC betrieben wird, ist keine Spannungsmessung und auch keine kalibrierung möglich. :/
https://www.shelly-support.eu/forum/index.php?thread/750-keine-energieverbrauchsmessung-und-kalibrierung-mit-dc-m%C3%B6glich/
Zitat von: Prof. Dr. Peter Henning am 31 Januar 2021, 22:15:07
Meine Güte...
Das Update wird mit "readingsBulkUpdateIfChanged" aktualisiert. Jetzt verstanden?
LG
pah
Hallo pah,
was ist eigentlich Dein Problem, dass Du ständig andere fhem user so arrogant runterputzen musst, wenn diese vermeintlich dämliche Fragen stellen - zumindest für ein so genialen Geist, für den Du Dich offenbar hältst?
Nicht jeder, der fhem benutzt, möchte eine oder mehrere Programmiersprachen lernen - genau deshalb existiert fhem und die entsprechenden Module überhaupt.
Wenn entsprechende Experten, zu denen Du ja ganz offensichtlich gehörst, Module schreiben und dankenswerterweise zur Verfügung stellen, ist das super. Viele andere Anwender wie ich sind dafür sehr dankbar. Nachfragen sollten erlaubt sein, auch wenn diese wie gesagt manchmal dämlich erscheinen. Ein kleiner erläuternder Hinweis hilft dann meistens.
Wenn Du der Meinung bist, dass die Beantwortung dieser Fragen unter Deiner Würde ist: lass es doch einfach. Evtl. findet sich ja jemand, der eine vernünftige Antwort geben kann...
Aber diese ständigen überheblichen Kommentare Deinerseits - nicht nur in diesem Thread - nerven extrem und nehmen einem die Freude an fhem.
Musste jetzt mal raus.
ZitatRichtig. Und warum?
Einfach nochmal meinen Post gründlich lesen - dann wird klar warum.
Weil hier wieder irgendwelche Leute glauben, dass sie zum Richter über andere bestimmt worden sind, ist dieser Thread ab sofort zu.
pah