Beiträge von 87insane

Hi nochmal...

Ich meine, wenn die Geräte eh so wenig brauchen, dann häng diese doch beide an einen Shelly.. Wäre der einfache Weg. Der Gesamtbedarf sollte dann messbar sein.

Zitat

Habe jetzt festgestellt dass ca. alle 30 Minuten der Wert relax_0_power mit ca 73 gefüllt wird. Diese KühlgefrierKobi ist ca 1/2 Jahr alt. Der Tiefkühlschrank - wesentlich älter - schreibt permanent werte zwischen 0.40 und 0.60.

Wenn relay_0_power mit Werten gefüllt wird ist doch alles super! Dann hast du doch was du wolltest...Bei dem einen Gerät nur leider viel zu wenig.

relay_0_power = Aktueller Verbrauch

relay_0_energy = Gesamt Verbauch

Hier eine Anmerkung: Der Wert 1 ist immer noch größer als 0.4 oder 0.6. Sollte also loadState immer auf off stehen...

Somit solltest du, mit dem bereits genannten einfach was bauen...

Der Teil hierunter, setzt das Reading loadState auf 1 oder 0.

shellies/SHELLY_NAME/relay/0/power:.* { my $compare = $EVTPART0 < 100 ? "off":"on"; ReadingsVal($NAME,"loadState","off") ne $compare ? { 'loadState' => $compare } : undef }

Sollte also nun loadState auf off gehen, muss du mit einem DOIF/NOTIFY einfach darauf reagieren. Ich gehe mal davon aus, ein Modul für Push Nachrichten aus FHEM heraus hast du bereits eingerichtet.

Du hast das Gerät leider in FHEM nicht neu angelegt. Da bringt dann das List nicht so viel. Ich gehe nun aber mal davon aus, es gibt kaum Änderungen.

Ich würde mir das dann so anpassen....(ungetestet, da kein FHEM hier):

shellies/SHELLY_NAME/relay/0/power:.* { my $compare = ReadingsAge($NAME,"relay_0_power",3800) > 3600 ? "off":"on"; ReadingsVal($NAME,"loadState","off") ne $compare ? { 'loadState' => $compare } : undef }

Eine Doppel-Prüfung auf einen Wert brauchst du meiner Meinung nach nicht. Es prüft nun einfach das Alter des Readings. Ist dieses älter als 3600 Sekunden (1 Stunde) oder aber er findet das Reading nicht, wird loadState auf "off" gesetzt. Testen kannst du ja indem du entweder das Gerät abklemmst oder einfach den Wert von 3600 anpasst. Die 3800 ist der Wert, wenn das Reading an sich nicht gefunden wird. Sollte aber nie vorkommen.

Das userReadings kannst du löschen. Brauchst du hier nicht. Wurde für Waschmaschinen und Trockner etc eingeführt. Es berechnet die Zeit, den Preis usw von einem Durchlauf.

PS: Auch wenn es so vermutlich gehen würde, spar dir nen Shelly und die Mühen. Häng beides an einen.... Du hast in meinen Augen keinen Vorteil durch zwei Shelly. Wenn nun eines der Geräte ausfallen würde, würdest du bei einem Shelly also auch ne Nachricht bekommen und könntest hinlaufen. Sobald beide an einem hängen, werden die Werte vermutlich auch besser gezeigt, da sie höher sind.

Bin über Feedback gespannt

Gruß,

Kai

Hey zusammen,

Zitat

Da kann Allterco aber auch nichts dran ändern.. der ESP8266 hat keine eigene Uhr, einzige Möglichkeit: Uhrzeit von einem Zeitserver holen..

Naja man könnte die Impulse aus dem Stromnetz nehmen. Machen normale digitale Uhren z.B. bei Rollo Schaltern oder Mikrowelle usw auch.

Tatsächlich habe ich ein logging über der RSSI und andere Werte, meiner Shellys. Es hat sich seit dem Update in richtung WLAN, nichts geändert!

Was die Zeitserver angeht und die Probleme mit Timern und co, hat Guzzi-Charlie eigentlich alles gesagt. Besser hätte ich es nicht sagen können. Habe am Pool z.B. einen Shelly. Der steht immer am Rand des WLAN und mal ist er da und mal nicht. Reicht also um die Zeit immer mal wieder ab zu holen. Tatsächlich ist es dann sogar so, dass wenn der Shelly sich wegen eines weekly schedules ein schaltet oder aus schaltet, meldet er sich ganz kurz wieder im Netzwerk. Reicht also für den Anwendungs-Fall. (nur als Beispiel)

Gruß,
Kai

Gegen nicht ankommende Message ggf. mal das QOS Level erhöhen. Dann müssen die ankommen.

Aber das eigentliche Problem wird wie von mat beschrieben sein. Kenne mich innerhalb von openhab nicht aus, ich nutze FHEM. In FHEM würde ich bei Event also flood = true direkt ne Push senden lassen. Hier wäre es egal ob das nur ganz kurz true und direkt wieder false ist, da ja ein event = true war.....

Gruß,

Kai

Guten Morgen,

du betreibst Mesh. Und die Einstellungen des Shellys hast du leider nicht mit gesendet. Ich habe in jedem Raum Sonos aber auch Shelly. Solche Probleme hatte ich nicht. Bei SONOS bin ich im Beta Programm und hatte das nichtmal mit den TEST Firmwares.

Gehen wir das mal logisch an....

FritzBox sendet WLAN xy

Shelly (wenn korrekt eingestellt) verbindet sich gegen WLAN xy

SONOS verbindet sich gegen WLAN xy.

Bei dir passiert (wohl bemerkt lt. FritzBox) etwas komisches!

FritzBox sendet WLAN xy

Shelly baut Verbindung zu FritzBox auf aber Repeatet das WLAN (nicht möglich)

SONOS hat ein eigenes MESH (wenn du mehrere hast). Aber diese verbindet sich via Shelly gegen den Router / FritzBox. Das halte ich für ausgeschlossen.

Also...

- Bitte mal deine Shelly WLAN Einstellungen posten (komplett bitte).

Wenn das so klappen würde, wie deine Fritzbox das anzeigt, bräuchte KEIN Shelly User mehr Repeater oder sonst was und hätte überall super WLAN. Wäre natürlich schon geil aber es ist aus anderer Sicht auch gut das es nicht geht^^

PS: Ich gehe davon aus, dass alles neu gestartet wurde...

Hey und guten Morgen Bernd + Helmut,

das wäre über ReadingsAge z.B. möglich sein aber in meinen Augen wäre das kein guter Weg.

Das was aber bereits im Template ist, ist der Teil hier:

shellies/shellyplug-s-266FC0/relay/0/power:.* relay_0_power shellies/shellyplug-s-266FC0/relay/0/power:.* { my $compare = $EVTPART0 < 100 ? "off":"on"; ReadingsVal($NAME,"loadState","off") ne $compare ? { 'loadState' => $compare } : undef }

Der ist genau für das gewünschte gemacht. Allerdings, wird das nicht klappen wenn der Shelly keine sauberen Werte liefert. Ich habe oft davon gehört, dass die Shellys im niedrigem Bereich nicht sauber messen. Ich selber kann Werte sogar bei 1W darstellen. Das wird aber wohl einfach Glück sein... ggf. sind es eher 1,5 und er zeigt 1 an.

In fast allen Templates gibt es ein Kommentar, wenn also was besonderes in dem Template ist, macht es Sinn, dass zu lesen

comment To get appropriate loadState values: Change the default limit "100" in readingList to your needs.

Vermutlich würde ich an deiner Stelle mal mit loggen wie oft du Werte bekommst vom Shelly. Das wäre nach den o.g. Dingen das zweite. (oben: Reset usw. um sauber zu starten).

Danach würde ich das loadState Reading anpassen um den gewünschten Wert zu erhalten. Da hat Bernd ja schon was zu gesagt. Aber erstmal ein bis zwei Tage loggen.... Ich vermute das das Gerät (wenn es so niedrige Werte hat) sicherlich länger als eine Stunde mal nicht Hallo sagt....

Gruß,

Kai

Gruß,

Kai

setz den mal komplett zurück. Wenn fhem keine werte bekommt, kannst natürlich nicht sauber messen.

Mich wundert das ein zweiter plug s bei dir das gleiche Phänomen zeigt.

Was das Endgerät an Verbrauch hat, kann ich so nicht sagen. Sicher wird er aber mehr als 2,3 watt ziehen. Demnach sollte auch was angezeigt werden.

Wasser soll inspirieren. An sich geht washer auch nur wenn du einen schwellwert eingetragen hast der realistisch ist. Erst wenn dieser überschritten wird, wird der Verbrauch angezeigt und Standby verschwindet.

Setz mal einen der shelly zurück und lass ihn durch autocreate neu erzeugen in fhem. Danach nochmal testen.

Dazu bitte dann ein neues list und deine genaue Idee, was du am ende haben willst. Denke das bekommen wir hin

Hey... Dann würde ich persönlich mal das "washer" Template testen. Da kannst du einen schwellwert angeben. Denke das sollte deine Anforderungen erfüllen. Hab mir dein list gerade nicht angesehen aber wenn das nötig wird oder da noch fragen offen sind, mache ich das. Markier mich einfach, damit ich ne Benachrichtigung bekomme.

Gruß,

Kai

Ich Danke für deine Unterstützung.

danke dir... Also wäre mit der Grund Idee genau das gewünschte möglich oder seht ihr da Probleme, die ich mangels Test nicht bedacht habe?

ps: also ein pw kann man vergeben via Web-if für den AP mode. Wo genau hab ich den hänger?

Hey und Danke erstmal!

Das muss ich gegen checken. Ich kann dem shelly doch sicher ein PW für sein Netz geben. Habe keinen eigenen anwendungsfall dafür. Aber dann muss ich mal gucken mit welchen shelly ich das teste. Im Notfall muss eben tasmota drauf.

Da aber alle AP Server auch Passwörter können MÜSSEN, shelly ne Zulassung hat, ist da was krum an dem Test. Finde es aber löblich, dass du deine Freizeit für mich genutzt hast! Hast n Bier bei mir gut

Hey zusammen,

aktuell habe ich einen Kollegen, der würde gerne eine Kreuzschaltung haben.

Nun ist es so, das KEINE Kabel zwischen den Schaltern vorhanden sind. Nun war die Idee einfach zwei Shelly 1 oder PM zu nehmen. Einen der beiden in den AP Mode versetzen und den anderen als Client dagegen zu verbinden.

Ich habe das noch nicht getestet aber würde dem einen Shelly (1) die Relays entkoppeln (in der Firmware / also SW Seitig) und den anderen Shelly (2) (der an der Lampe hängt) würde ich normal schalten lassen. Zudem würde ich dann in dem Shelly (1) eine on/off URL hinterlegen, die auf Shelly (2) verweist. Als Schalter Einstellung würde ich vermutlich einfach toggle wählen.

Ist das an sich korrekt oder geht das ggf. sogar einfacher?

Anforderungen sind:

- Wechselschaltung

- Strom in beiden Dosen aber keine Verdrahtung untereinander

- KEINE Nutzung der App

- KEINE Nutzung, der lokalen WLAN Anbindung. (Sollen die Shellys unter sich machen)

Hoffe ich habe auf die Schnelle jetzt nichts vergessen.

Gruß,

Kai

jaein... Hier kann man nun viel biegen.

1. geil das du das selber herausgefunden hast! Du hast dir das vorhandene reading einfach übernommen. So kannst du einstellungen setzen. Auslesen geht natürlich auch, da ja schon vorhanden.

2. in fhem gibt es x module. Damit diese alle ohne großes zu tun zusammen arbeiten, gibt es regeln. Diese sind zb auf die pct bezogen. Mit deinem ansatz könnte man das quasi klonen. Ist am ende aber nicht das ziel. Man will das system ja nicht wegen x Zusatz aufgaben lähmen. Klar, es müssten diverse sein damit das eintritt.

Ergebnis: du hast erstmal was du willst aber ich empfehle dringend (wegen der Kompatibilität) wenn das template fertig ist, dies zu übernehmen. Bohald hat ja bereits ein Beispiel genannt. Das zieht sich aber durch die ganze Palette durch. Geht zwar alles auch mit anderen befehelen oder wörtern, muss man aber selber mappen. Das kann in einigen Fällen echt ein sehr extremer und nerviger Aufwand sein.

Gruß,

Kai

Du natürlich nicht. War an alle gerichtet, bei denen sich das lohnt. Würde es an deiner stelle vermutlich auch woanders bestellen.

uff...hier ist ja was passiert.

Da ich nur am Handy sitze, kurz.

Das bezüglich mqtt2 test bekam ich mit. Allerdings nahm rudolf kaum deinen raspi auseinander. Hier wurden entscheidene hinweise von supernova1963 gegeben. Klar kann ich mir mehrere autos mit 800ps kaufen. Aber ich sollte sie zumindest auf der strecke halten können. Ich habe noch immer nicht gezählt aber ich hab, wie schon erwähnt auch x Geräte. Alles auf wirklich nur einem raspi 3. finde das event on change beispiel relativ gut, da ich ja auch nicht überall licht anlasse, nur weil ich überall licht hätte. Ist eben eine kleine bedarfs Analyse.

Zur umbenennung der shelly. Bedenke das die topics weiterhin gleich rein kommen. Seit der letzten firmware kann man das direkt umbenennen. Macht es ggf. einfacher wenn man verschachtelungen hat. Ich selber habe nur aliase für die Geräte. Belasse es auch bei den topics. Liegt aber an der Vielzahl, der Geräte. Würde ich jetzt neu anfangen, würde ich die topics umbenennen. Streng nach etage_raum_was_ist_es. Aber eben immer so das auch regex passen würde auf einfache art und weise. Regex zb geht immer aber man muss es sich ja nicht unnötig kompliziert machen.

Würde an der stelle aber gerne noch etwas hinzufügen: ich finde es super das sich hier alle damit auseinander setzen. Allerdings sollten alle auch ein wenig googlen oder ins wiki sehen. Tatsächlich wird das garnicht gern gesehen, dass zb ich hier ne Art anfänger Hilfe mit betreibe. Kann es in so fern nachvollziehen, da man sich die Lösungen auch ein wenig erarbeiten sollte. Das schöne daran ist das mam am ende echt stolz ist und auch versteht wie die dinge laufen. Alleine aus sicht der sicherheit ist das schon wichtig (in meinen Augen).

Jeder sollte wissen was ein list device ist. Jeder sollte die Grundfunktionen kennen sollte dem nicht so sein -> nutzt die (ungern gesehene) hilfe und schreibt das als Frage in den jeweiligen Bereich. Die FAQ im fhem bereich ist ein wenig gewachsen aber man braucht sich auch nicht schämen. Besser wir erfassen alles als zu wenig. Mir ist es auch egal ob mein name drüber steht. Darf gern jemand anderes drüber stehen

Geht mir darum, dass ich mir ein wenig Sorgen mache. Zum einen ob man die Posts nicht ein wenig eindämmen und lenken kann und zum anderen um die Benutzer, die es "einfach mal so" einrichten. Wir reden über angreifbare infrastrukturen .... Da wird am ende die als sicherheit gedachte kontaktschaltung zu einem risiko. Also besser eine frage zu viel -> dafür aber sicherheit und zusätzliche inspirstion ?

Mal davon ausgegangen, die events sinnvoll begrenzt zu haben, sollte locker klappen. Auf meinem raspi habe ich dazu sogar noch 433/868mhz am laufen. Wandlung von IR zu RF und verknüpfte befehle dahinter.

Da muss was krum gewesen sein. Da würde aber wirklich nur eine detail konfig helfen.

Für fhem habe ich genau einen raspi 3. dieser steuert von thermostaten (868 MHz) über simple umwandlung oder aber auch mqtt geräte. Will nur kurz verdeutlichen, dass es laufen sollte. Da alles sequenziell durch läuft, muss die flut bewältigt werden. Geräte erstmal einbinden und schauen was man will. Danach die events resuzieren auf das was man braucht. Selebst ein "event-on-change .*" in 99% der geräte sorgt für geschmeidigkeit. Bei den wenigsten braucht man mehr. Danach kann man noch weiter gehen und nur noch nehmen was man braucht. Ich muss unbedingt mal alle Geräte im detail durch zählen. ? danke für die Idee.

Soll nicht eingebildet klingen. Denke aber wir würden hier noch so einige ideen vereinen können super Themen für die fhem FAQ. Danke!

Hey und guten Morgen,

da leider bisher keine Reaktion kam, mache ich mal den Anfang.

F: Woher kommt der Online-State vom Shelly, bzw. wovon ist dieser abhängig?

A: Der Online-State des Shelly mit MQTT, basiert auf einer offenen und akzeptierten Verbindung gegen einen MQTT Server. Dieser hat nichts mit der WLAN Qualität des Shelly zu tun. Auch ist hier zu beachten das nicht alle HTTP GET Infos via MQTT verteilt werden. Hier wird der Hersteller vermutlich aber noch dran arbeiten. Sollte ein Shelly offline gehen, wird sein LastWill ausgeführt. Dieser ist bei Werkseinstellungen "shellies/shellyname/online false". Sollte der Shelly sich also im eingestellten Intervall nicht erneut melden, weiß der Server was der LastWill ist und setzt online = false.

Quelle: Bedeutung des MQTT-statements "online"

dürft mich da gerne als Berater angeben, beim einkaufen

Danke supernova1963 - für deine schnelle Antwort.

Ich persönlich würde seit Implementierung des MQTT2 Servers in FHEM, immer umstellen. Habe bisher noch keine negativen Erfahrungen machen können.

Wird bei uns noch diskutiert. Wir sind uns noch nicht einig wie es am ende sein soll. Denke bis zum ende der Woche, haben wir ein ergebnis.