Beiträge von 87insane

Ja gut wenn es dir egal ist kannst du dir einfach ein doif/notify anlegen und schalten lassen. Oder du kannst die on/off URLs in den shellys nutzen. So kannst du sicher sein das wenn Befehl eins ankommt, Befehl 2 ausgeführt wird auf anderer Seite.

Gruß,

Kai

In meinen Augen MUSS das direkt am Gerät passieren. Es darf in keinem Fall über fhem o.ä. laufen. Sollte mal das WLAN weg sein......oder...oder....

Also muss man das in den shellys hinterlegen. Da sehe ich aber nur den Weg über eine wechselschaltung. Hab mir nun aber nur grob durchgelesen was hier wo getan wurde. Langer Thread....

Gruß,

Kai

Guten Morgen. Den Befehl in devstateicon mit ein zu bauen sehe ich nicht als schwer an. Nun müsste man nur über die fhem Instanz die ganzen Serien abfragen und gucken ob was vorhanden ist. Danach, die Update Datei auf dem Pi/Server oder sonst wo speichern....

Sehe da kein großes Ding.

Hinweis:

http://ip_vom_shelly/ota?url=http://hier_deine_quelle.zip

Gruß,

Kai

Ich denke für das FAQ ist das hier leider nichts. Ggf kann ein Admin ein eigened Thema daraus machen?

Ich selber habe in meinem Fhem WebIF alles einheitlich gestaltet. Zumindest da wo es ging. Vom Design her fällt es also nicht auf ob es ein shelly oder sonoff oder sonst was ist. Das einzige was leider nicht geht ist die automatische abfrage und Info via mqtt bei tasmota. Aber dann kann man den gelben Punkt da auch einfach weg lassen. Ich bin bei tasmota eh kein großer freund davon, einfach mal ein update zu machen. Tasmota kann einfach so unendlich viel, das oft ein update mit anschließendem neu einstellen des Gerätes verbunden ist.

Das sieht für mich einfach wie ein WLAN Schalter aus. Hoffentlich ein eigenständiges MQTT Gerät. Denke mal ist die Vorstufe zum Schlüsselanhänger.

Hoffentlich nicht "nur" ein WLAN http Mod.

Kurz weil Handy...

Es lohnt immer mal wieder ins comandref zu sehen. Ich gucke quasi täglich da rein.

deltaReadings <Gerätewerte>
Durch Kommas getrennte Liste von weiteren Gerätewerten, für welche die Differenz zwischen den Werten am Anfang und Ende einer Periode (Stunde/Tag/Monat/Jahr) bestimmt wird.

Lass dich nicht verwirren.. versuche es durch testen oder lesen heraus zu finden. Am Ende kann einen das nur weiter bringen. Ich kann natürlich für jeden und alles meine Dienste anbieten aber man muss auch nicht übertreiben. Wenn du eine fertige Lösung hast, kannst du diese, wie immer gerne präsentieren. Am Ende hilft das dem nächsten, der es nachbauen will sicher

Wobei diese Sache, nachdem da mehrere Personen Probleme mit hatten, eh in die Templates kommt. Die FHEM Templates sind aktuell komplett in Überarbeitung. Die Sprachsteuerung geht schon x mal besser als vorher schon (die war schon super gut). Bei Auswahl eines Templates bekommt man nun quasi die wichtigsten Dinge angezeigt und muss sich nur noch durch klicken.

Ich hatte ein wenig gehofft das wir hier keinen workaround benötigen sondern Shelly das direkt mit einbaut. Da dies aber wohl nicht passiert, müssen wir uns dann wohl doch selber helfen (hierzu wollte ich keine OT Diskussion entfachen. Warum das so ist und warum das von beiden Sichten her Sinn macht wurde ausreichend besprochen, in diesem Forum )

Gruß,

Kai

Nur mal so am Rande.. das ist ein wenig mehr als ein Jahr (375 Tage). Wird kein Gerät für mich....

Danke für die ganzen Infos!

Idee gut, Preis heftig (159.00€).

Bin gespannt ob das Projekt ans Leben kommt. Ich selber würde zum testen gerne einen nutzen aber zum testen ist mir das zu teuer.

Gruß

Guten Morgen zusammen,

naja ich mache das ja nicht auch um sonst beruflich

Gebe nochmal einen kleinen Hinweiß.

Zwei Dinge sollen es am Ende sein.

1. Energie-Messung, die nicht resettet wird.

2. Energie-Messung, die auch in Tage/Wochen/Monaten/Jahren usw sinnvoll ist. (das hier macht Statistics) = Ist also fertig

Zu 1) Hier kann monotonic helfen. Sende mal ganz platt ein Beispiel. Die Readings muss du auf deine anpassen...

attr GERÄTENAME userReadings relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsVal("$name","relay_0_energy",0)}

Damit würde ein Reading mit dem Namen relay_0_energy_total erzeugt werden. Dies würde ich dann wie gewünscht, bei den entsprechenden Geräten hinterlegen. Danach hast du vermutlich was du magst

https://fhem.de/commandref_DE.html = Suche nach monotonic

Anbei noch ein kleines Bild, das zeigt wie ich das meine und das es auch klappt:

Gruß,

Kai

Achso, hat tasmota ein reading bei dem es sagt es wäre ein update verfügbar? Bin mir nicht sicher und kann gerade nicht nachgucken. Sollte dem nicht so sein geht nur online/offline und webinterface bei Klick.

Ist in sofern falschen Thread aber ich denke für die FAQ gut. Daher muss ich ihn auch in Schutz nehmen. Sagte ihm er soll bitte öffentlich Posten.

Das man als "Neuling" überall versucht seine Infos zu bekommen, ist okay.

Danke für die weitere Frage. Nehme das gern in der FAQ auf und die Antwort mit den fertigen readings lieferst du dann. Kannst du auch im fhem Forum posten oder ich geb es weiter. Solltest du weitere Fragen haben, gerne...

Ei Ei Ei... Was ist denn hier los...

An die OT Diskussion hänge ich mich nicht.

Ich mag beide Firmwares.

Soooo es geht natürlich. Da alle meine tasmota Geräte aber andere zwecke erfüllen brauchte ich es da nicht. Deswegen muss du Dir das selber ein wenig anpassen. Das geht in meinen Augen einfach.

Schau dir mal devstateicon in zb einem shelly 1pm an. Also das was für shelly fertig in fhem ist. Dann nimmst du anstelle der readings, die die shelly Firmware erzeugt, einfach die, die dein tasmota Gerät für den gleichen Zweck erzeugt. Bei shelly ist zb "online" = "true", was bei tasmota für normal LWT sein sollte. Identische Funktionsweise, wenn du alle readings korrekt tauscht.

Gruß,

Kai und bitte nicht weiter zanken

Nochmal kurz Edit bevor es heißt ich hab was übersehen : https://svn.fhem.de/trac/browser/t…/mqtt2.template

Da kannst du dir alle templates ansehen. allerdings eben in roh Form. Du nimmst dir bitte das oben erwähnte devstateicon für shelly 1 energy mess.... Alle readings tauschen wenn nötig und danach löscht du wenn vorhanden noch stateformat. Einige arbeiten damit andere nur über devstateicon mit Perl. Das würde sonst neben effekte haben die echt lustig sein können.

Hey zusammen....

da ich aktuell starke Knie Probleme habe, melde ich mich nur bedingt.

Aber wie @hemli55 schon sagte, muss man einfach das entsprechende shelly attr Template auswählen. Diese sind im großen und ganzen durch mich mit entstanden. Ich habe anfangs ewig gebraucht und viel lesen plus Hilfe. Aber einmal verstanden, geht das ganz einfach.

Lange Rede kurzer Sinn....

Gibt für jeden shelly bzw funktionsbedingten shelly ein template. Wenn neue shelly kommen, ist das auch relativ schnell in der Template Datei enthalten.

Wenn ein shelly via autocreate über fhem mqtt2 Server in dein fhem rein läuft, klickst du auf das neue Gerät, und kannst ganz oben eh nur eine Option bei set wählen. Und im letzten der dropdown Menus stehen die Namen der templates. Einfach mal testen welcher für deinen Zweck am besten ist. Habe versucht alle shelly templates, an denen ich mitgearbeitet habe, gleich aussehen zu lassen bei maximaler Effizienz. Deswegen war die "ampel" auch so ein schönes System.

Soooo genug geschwärmt und selbst gelobt. Viel Spaß beim testen

Gruß,

Kai

Ich versuche es mal mit der Doku:

• shellies/shellyem3-<deviceid>/emeter/<i>/energy an incrementing energy counter in Watt-minute
• shellies/shellyem3-<deviceid>/emeter/<i>/returned_energy energy returned to the grid in Watt-minute
• shellies/shellyem3-<deviceid>/emeter/<i>/total total energy in Wh (accumulated in device's non-volatile memory)
• shellies/shellyem3-<deviceid>/emeter/<i>/total_returned total energy returned to the grid in Wh (accumulated in device's non-volatile memory)
• shellies/shellyem3-<deviceid>/emeter/<i>/power instantaneous active power in Watts
• shellies/shellyem3-<deviceid>/emeter/<i>/reactive_power instantaneous reactive power in Watts
• shellies/shellyem3-<deviceid>/emeter/<i>/voltage grid voltage in Volts
• shellies/shellyem3-<deviceid>/emeter/<i>/current current in Amps
• shellies/shellyem3-<deviceid>/emeter/<i>/pf power factor (dimensionless)
• shellies/shellyem3-<deviceid>/relay/0 reports status: on, off or overpower

Zitat von eddie

Ich habe die REST-Schnittstelle getestet. Das geht mit FHEM ganz easy going. Man definiert sich ein HTTPMOD-Device und man kann bekommt alle Felder angezeigt:

Code

define Shellytest HTTPMOD none 0
setuuid Shellytest 5e5b91ed-f33f-5ef7-548f-28d7caf1a43149e2
attr Shellytest userattr get01Name getHeader1 getHeader2 getURL reading01JSON
attr Shellytest extractAllJSON 1
attr Shellytest get01Name shelly_data
attr Shellytest getHeader1 Content-Type: application/json
attr Shellytest getHeader2 Accept: */*
attr Shellytest getURL http://192.168.1.146/status
attr Shellytest reading01JSON modes

Da zeigt es sich, dass alle Energiewerte in Wattminuten übertragen werden. Das heißt um die KWh auszurechnen muss man durch 60 teilen um auf Wattstunden zu kommen und dann mit 1000 teilen um einen Wert in KWh zu bekommen.

Aus:

Code

meters_01_total = 1464 

wird 1464 Wm / 60 / 1000 = 0,0244 KWh

Ich habe mir ein UserReading energy_0 angelegt, um konform mit meinen Homematic-Komponenten zu sein. Dort findet sich dann ein Wert in Wattstunden wieder:

Code

energy_0 = 24.5 

Hier sind die Definitionen für meine UserReadings:

Code

energy_0 {sprintf('%.1f',ReadingsVal("Shellytest","meters_01_total","0")/60)},
energy_1 {sprintf('%.1f',ReadingsVal("Shellytest","meters_02_total","0")/60)},
energy_2 {sprintf('%.1f',ReadingsVal("Shellytest","meters_03_total","0")/60)},
energy_3 {sprintf('%.1f',ReadingsVal("Shellytest","meters_04_total","0")/60)},
energyCalc_0 monotonic {sprintf('%.1f',ReadingsVal("Shellytest","meters_01_total","0")/60)},
energyCalc_1 monotonic {sprintf('%.1f',ReadingsVal("Shellytest","meters_02_total","0")/60)},
energyCalc_2 monotonic {sprintf('%.1f',ReadingsVal("Shellytest","meters_03_total","0")/60)},
energyCalc_3 monotonic {sprintf('%.1f',ReadingsVal("Shellytest","meters_04_total","0")/60)},
power_0 {ReadingsVal("Shellytest","meters_01_power","0")},
power_1 {ReadingsVal("Shellytest","meters_02_power","0")},
power_2 {ReadingsVal("Shellytest","meters_03_power","0")},
power_3 {ReadingsVal("Shellytest","meters_04_power","0")},
relay_0 {if (ReadingsVal("Shellytest","relays_01_ison","0") eq "1") {"on"} else {"off"}},
relay_1 {if (ReadingsVal("Shellytest","relays_02_ison","0") eq "1") {"on"} else {"off"}},
relay_2 {if (ReadingsVal("Shellytest","relays_03_ison","0") eq "1") {"on"} else {"off"}},
relay_3 {if (ReadingsVal("Shellytest","relays_04_ison","0") eq "1") {"on"} else {"off"}}

Alles anzeigen

Alles anzeigen

Schrieb ich ja oben. Der Auto schrieb mir via pn das ein FW uodate geholfen hat.

Lösung ist aber in meinen Augen auch der durch uns benannte weg. Die Werte von mqtt und coap sind die gleichen. Also ist die umrechnung auch die gleiche.

Zwar OT aber was findest du besser an der REST Schnittstelle als an mqtt? (Pro / kontra) wäre echt interessant aus anderer Perspektive

Sehr schön

Was soll ich sagen. Bei mit hab ich überall diese Berechnung. Passt auch von den Werten her. Allerdings sind es bei mir fast überall 1er oder 2.5er shellys mit LED Beleuchtung dahinter. Also niedrige Werte.

Hab aber zb auch einen plug s an einer Waschmaschine. Die Werte passen auch. Lasse mir sogar via push den Verbrauch senden.

Wenn sich seit meiner rückrechnung in der Firmware, etwas geändert hat, mag es sein. Kann ich mir aber nicht vorstellen. Dann würden meine Werte auch krum sein.

Ps: alle die FHEM benutzen und die templates, nutzen das auch so. Spätestens da hätte sich jemand melden müssen. Bin mal gespannt ob hierdurch nochmal was hoch kommt.

Für mqtt hatte ich das im FAQ erwähnt. Da geht es um fhem aber die umrechnung ist die gleiche.

[GELÖST] - MQTT /relay/0/energy:.* Wert

Gruß,

Kai

Ja