Beiträge von 87insane

Guten Morgen,

für ein genaues Bild brauch ich leider ein list des Gerätes. Alles andere wäre raten.

Gruß,

Kai

Hey der.fpg

Sende bitte mal ein list deines devices. Bzw auf jeden Fall wären die readings interesant die du geloggt haben willst. Dann kann man via event-on-change eine regex dafür bauen. Alles was uninteressant ist, würde dann zwar aktuell gehalten aber kein event triggern.

Das logging selber wird in der Definition des Log devices eingeschränkt. Ist aber auch schnell gemacht.

Bin gespannt was es bereits gibt bei dir. Ggf noch ein userreadings für c aber auch das sollte schnell gehen. Hab das template für den 3em nicht im Kopf aber mit einem list deines Gerätes kommen wir sicher weiter.

Ps: im fhem Forum redet ihr gerade alle aneinander vorbei ... Beta-user wollte sicher nur helfen aber das wirkt schnell so als würden die kollegen meckern. Problem sind immer wiederkehrende Fragen die man nicht stellen würde, hätte man das comref gelesen. Das ist hier tatsächlich ein solcher Fall. Aber ich glaube das ein Beispiel hier nicht schaden kann. Daher würd ich das nun einmal versuchen durch zu gehen mit dir und am ende haben wir ein kleines FAQ für jederman

Gruß,

Kai

Hey und guten Abend.

In meinen Augen helfen je nach Anwendungsfall, a) das update Intervall im Shelly ändern um den Verkehr generell zu minimieren.

Oder b) in fhem sauber filtern. Filtern über event-on-.* ist im meinem Augen auch das sinnigste. Zum einen ist fhem Event basierend und daher würde ich bei jedem Gerät, alles weg filtern was man nicht braucht. Zum anderen macht das aber auch Sinn um die Last massiv zu senken. Die templates sind immer ohne event-on XYZ da man nie weiß was der Benutzer am ende machen will. Es macht aber natürlich sinn, gerade bei solchen Geräten wie dem 3em die Infos ein wenig kleiner zu halten.

Deswegen die Frage. Was genau soll "weniger" werden? Und was genau ist das Ziel?

Gruß,

Kai

der.fpg was "plagt" dich denn?

Gruß,

Kai

Hey,

tatsächlich kann ich dir das beim 3EM garnicht sagen, da ich keine Test Hardware (3EM) aktuell hier habe. Kann mir das aber kaum vorstellen, dass es fehlt.

Ggf kann 66er oder einer der anderen Mods dazu was sagen.

Gruß,

Kai

Guten Morgen.

Das kann an den wildesten Dingen liegen. Hatte aber nun diverse Kunden und auch bei mir zuhause das Thema. Bei mir betraf es nur ein Rollo bei den Meisten Kunden allerdings viel mehr Geräte.

Das Verhalten der Shellys passt aber perfekt zu deiner Beschreibung.

...nach ein paar Stunden offline...nur Sicherung raus/rein hilft.

Gruß,

Kai

Hey und guten Mittag,

schalte den ECO Modus unter Einstellungen des betroffenen Shelly aus. Danach hast du das Problem nicht mehr.

Gruß,

Kai

Hey und guten Abend!

Freut mich! Aber darf ich fragen wozu du das in dem dummy schreibst? Ggf. bringt mich das auf weitere Ideen

Vom Grundsatz her melden alle diese Geräte bei mir z.B. an einen mswitch oder was man so gern hat (notify/doif) und der erzeugt die Nachricht für den Bot und sendet. Das hab ich sehr offen gehalten, damit jedes Gerät sich da dran hängen könnte. Aktuell nur Wasch.-/Spülmaschine und der Trockner. Gleichzeitig spart man so natürlich separate Geräte. Ist natürlich für fhem erstmal egal.

PS: Der Thread ist ja nun da und ggf können wir den noch ein wenig ausbauen. Ist das okay für dich, wenn ich den im FAQ verlinke? Ich persönlich mag es sowas gesammelt / zentral zu haben

Gruß,

Kai

Hey und guten Abend,

du hast quasi schon 90% deines Wunsches fertig

Die Zeile in readingList muss angepasst werden:

shellies/shelly1pm-34AB953806E9/relay/0/power:.* { my $compare = $EVTPART0 < 100 ? 'off':'on';; ReadingsVal($NAME,'loadState','off') ne $compare ? { loadState => $compare } : return }\

Die 100 muss angepasst werden.

Wenn dort der korrkte "Schwellwert" drin steht (wie in deinem DOIF), wird schonmal angezeigt ob die Maschine läuft oder nicht.

Leider hast du die Readings rauß genommen aus dem RAW. Daher kann ich nicht sehen was drin steht.

Normal würde nun beim waschen mit dem korrekten Schwellwert, am Ende berechnet werden wie lange sie lief, wie teuer dies war usw.

Hier muss du vermutlich im Userreading (price) noch deinen Preis Dummy angeben oder aber die 0.30 anpassen.

Wenn das erledigt ist hast du alles in den Readings stehen und kannst dir das senden.

In Kurz zusammengefasst:

- Schwellert in readingList anpassen

- Richtigen Strompreis in userReadings "price" angeben

Ich bin gespannt auf dein Feedback.

Gruß,

Kai

Hey und guten Abend. Leider habe ich das nicht eher geschafft, aber es auch nicht vergessen.

Du hast im Template des shelly sogar mehr als du ahnst. Das diof für laufende maschine wird damit überflüssig. Die userreadings zeigen auch die Energieberechnung auf. Ich melde mich morgen nochmal wenn ich am pc sitze.

Am besten sendest du ein raw des shellys aus fhem. Dann kann man schon mal sehen was ggf fehlt oder noch angepasst werden sollte. 3/4 der Arbeit hat's du ja schon.

Gruß,

Kai

Hey helmi55 - ich verstehe leider die Frage nicht. Oder ist das eine Aussage?

Hab im FHEM Forum aber mal geantwortet.

Gruß,

Kai

Hey und guten Morgen...

kannst du ein RAW vom Gerät in Fhen Posten?

Gruß,

Kai

Hey nochmal... Ich behaupte du versuchst das Gerät zu schalten, welches über die shelly cloud kommt. Du muss aber das Gerät, das über FHEM kommt schalten.

Das kann man erkennen, wenn man in der alexa app ein Gerät wählt und dann auf das zahnrad klickt. Zusätzlich muss das Gerät natürlich einen eindeutigen Namen haben.

Screenshot_20220411-175921~2.png

Was genau ist denn der Fehler den die Sprachassitenz sagt?

"Device Name reagiert gerade nicht", würde für meine Theorie sprechen.

Gruß,

Kai

Ich nehme mal folgendes an:

- Fhem kennt den Status von kodi

- der/die shelly sind via mqtt und Template in fhem angelegt

- alexa fhem läuft

Wenn das so ist, geht mqtt und alexa. Die Geräte werden dann natürlich über fhem bereit gestellt innerhalb von alexa. Die shelly cloud ist/muss dann aus. Bei mir zb ist nichts über die shelly cloud am laufen. Trotzdem kann ich via Sprache, mqtt, Rest oder sonst was mit den shellys arbeiten.

Dann brauchst du eigentlich nur noch ein doif/notify oder mswitch. Egal was von den dreien, würde dann einfach set device off ausführen und das licht würde ausgehen. Wo genau du jetzt hängst, weis ich leider nicht :-/

Beispiel mit einem notify:

define name_vom_notify notify kodi:reading:play {fhem("set shelly_name off")}

Gruß,

Kai

Moin moin,

fhem("set device_name comand");

Alexa-fhem ist nur dafür, das du via alexa steuern kannst. Fhem selber als Server steuert die Geräte ja nicht über alexa sondern mqtt.

Der Befehl oben ist am ende ja nur dafür, in zb Perl wieder "fhemisch" zu sprechen

Ich verstehe das Vorhaben aber auch nur halb. Normal würde ich das mit doif/notify/mswitch innerhalb von FHEM machen.

Wenn ich dir so nicht helfen konnte, Schlüssel das gewünschte bitte ein wenig mehr aus

Gruß,

Kai

Kino.80 du muss dich nicht entscheiden. Nur eben deine alexa Geräte wie shelly, die über fhem kommen, über alexa-fhem laufen lassen.

Gruß,

Kai

Freut mich gleich doppelt!

1. Fehler gefunden.

2. mqtt Client in Gebrauch.

Ich weiß es geht natürlich auch mit httpmod usw. Aber so ist es sauber (in meinen Augen).

Noch ein 3. Du hast ohne weitere Hilfe, einfach mit den Stichworten gearbeitet und es hin bekommen. Das ist (falls es sich anders lesen sollte) zu 100% positiv gemeint!

Ich behaupte sogar, die Nachwelt würde sicher gern mehr lesen dazu. Leider schaffe ich das zeitlich aktuell nicht.

Aber die Idee wäre, du schreibst das ggf. für die Nachwelt auf und alle hier können es mit ausarbeiten. Gerade beim möglichen Filtern, wird es sicher nochmal spannend. Ich würde mich natürlich beteiligen und ggf. bekommen wir dein System sogar noch ein wenig runder

Gerade bei mqtt und shelly sind gewisse stichworte noch interessant.

"event-on-change" wäre so eins. Die templates beinhalten es nicht aber Minimum .* sollte sein. (Es gibt natürlich Ausnahmen)

Alleine das nicht immer, bei jedem value ein Event auf fhem seite ausgelöst wird, beschleunigt das System enorm.

Gruß,

Kai

Hey - Kino.80 du kannst aber fhem und alexa koppeln. Das ist sogar super einfach geworden und funktioniert 1A. Durch die vorhanden templates muss man meist nicht mal die homebridgemappings anpassen.

Einfach mal nach dem fhem connector für alexa googlen. Es geht natürlich auch ohne den fhem vereinsserver, ist aber für viele vermutlich etwas zu umfangreich.

Teste es mal und lass gern Feedback hier

Seven of Nine Wieso sollte fhem das nicht können?

Interessanter ist aber die Frage, warum sollte man ein weiteres Protokoll aktivieren, wenn eins reicht? Also egal ob nun mqtt oder coap. Man könnte nun zusätzlich über REST sprechen was an sich ja in coap steckt aber hier sogar noch als dritte Möglichkeit gegeben wäre 😅

Ich bin mal frech und füge hinzu: fhem kann bis auf von alleine schön aussehen, alles was die anderen auch können. Durch das Alter sogar noch mehr. Es ist nur nicht über all "klicki bunti", stimmt.

Das einzige was man hier entscheiden müsste, welchen Weg will man gehen... Für mich persönlich macht es wenig Sinn die shelly cloud zu nutzen wenn ich eine der genannten Sub Lösungen nutze. Am ende steht natürlich, wenn auch bei vielen nur minimal, die frage nach der Sicherheit.

Das ist hier aber in keine Fall als angriff zu betrachten. War beim Lesen nur ein wenig erschrocken.

Gruß,

Kai

Hey,

grundsätzlich finde ich das ganze besser mit nur einem Server außer es wäre wirklich getrennt. Also physisch oder vlans usw...

Zuerst wäre nun aber interessant warum ein Gerät die Daten nicht immer überträgt. Ist die ggf Funk Strecke nicht optimal? Senden das Gerät ggf nicht immer oder muss etwas anders konfiguriert werden?

Alles um zu bauen mit dem ggf gleichen Ergebnis am ende, ist ja nicht das Ziel.

Ich selber nutze gerne den mqtt2 Server und das aber auch auf dem gleichen Server wie fhem. Sehe wenig nutzen den Server wirklich auf einem eigenen Pi laufen zu lassen. Tatsächlich passiert dort Lasten technisch auch bei den sehr gesprächigen shellys, wenig.

Gruß,

Kai

Hey zusammen,

generell mal die Frage - warum zwei mqtt server?

Man könnte über diverse wege die Daten des Server 1 von Server 2 mitlesen usw. Aber dann macht die Trennung wieder weniger Sinn. Ein Beispiel wäre es zb auf Server 1 einen Client gegen Server 2 sprechen zu lassen. Dann könnte dieser erstmal alles lesen. Das kann man dann runter filtern, bis nur noch das gewünschte über bleibt. Eben um die Last gering zu halten. Aber das ist auch wieder von hinten durch die Brust....

Hier brauch ich mehr Infos, um zu verstehen was genau, und warum so ist.

Die Anzeige auf deinen Tablets, ist via smartvisu, etc oder einfach die jeweilige fhem Instanz? Die Trennung der anzeige könnte je nach Vorhaben auch mit nur einer fhem Instanz wunderbar funktionieren.

Gruß,

Kai