Neueste Beiträge

#1

Sonstiges / Aw: aWATTar in Deutschland ver...

Letzter Beitrag von TheTrumpeter - 07 Mai 2024, 09:30:01

ja

Hm... dann muss ich mir das nochmal anschauen. Ich habe den Code in den UserReadings etwas angepasst, wenn ich mich richtig erinnere, weil irgendwas nicht richtig funktioniert hat. Möglicherweise hab' ich da einen Fehler gemacht.

"on" kommt erst wenn ich ,wie heute, um 10:00 erneut abfrage

Ja das liegt in der Natur der Sache. Irgendwas muss das Event ja erzeugen. Du kannst entweder stündlich abfragen (so mache ich es) oder stündlich die Werte aus fc0_xx_total auf current_price schreiben. (Das hab' ich früher so gemacht bevor ich auf die Definition von ch.eick umgestiegen bin.)

#2

Off-Topic / Aw: Lidl WI-FI Steckdose SWS-A...

Letzter Beitrag von biopio - 07 Mai 2024, 09:29:10

@epek:
Wir drehen uns etwas im Kreis. Ich kann Dir nicht erklären, wie die Dose den Broadcast empfangen kann. Ich merke wohl, dass Dir das viel Kopfzerbrechen bereitet, aber ich und das Python-Modul, das ich geschrieben habe, können Deine Fragen nicht beantworten.

Ich habe bei meinem Rumprobieren seinerzeit auch schon Dosen den Totalreset verpasst und sie anschließend wieder angemeldet bekommen. Und Dosen, die vorher in einem anderen Netz angemeldet waren (gebraucht gekauft).

Ganz unabhängig vom Anmelden einer neuen/resetteten Dose kannst Du ja noch nicht einmal die schon im Netzwerk verbundenen Dosen mit meinem Modul ansprechen. Das spricht doch stark dafür, dass es a. entweder Probleme mit meinem Modul generell gibt (was ich nicht glaube, weil ich es zu Hause regelmäßig benutze), oder b. mit dem Modul unter Linux oder c. mit Deinen speziellen Netzwerk-Settings oder, oder, oder... (Firewall, Broadcasting unterbunden, ...)? Versuch doch erst mal hinzubekommen, dass die verbundenen Dosen auf ein `find_sockets()` reagieren. Oder sie direkt zu schalten, wenn Du Ihre IP- und MAC-Adresse ausfindig machen kannst. Vorher macht alles andere keinen Sinn.

#3

MQTT / json2reading im Userreading nu...

Letzter Beitrag von Tobias - 07 Mai 2024, 09:04:56

Hi,
ich habe jetzt neu einen "Shelly Plus PM Mini" am laufen. Dieser liefert alle Werte zusammen in einem JSON. Alle meine vielen anderen "alten" Shellies liefern jeden Einzelwert in einem eigenen Topic. Das stellt mich vor die Herausforderung jetzt noch zusätzlich das JSON parsen zu müssen um jeden Wert in einem einzelnen Reading zu haben.
Dazu habe ich mich bzgl json2reading schon schlau gemacht. Ist eigentlich genau das was ich brauche. Ich habe auch das Modul ExpandJson gefunden, möchte es aber nicht einsetzen da es wieder ein neues Modul ist und für jedes MQTT Device mit JSON-NAchrichten ein ExpandJson MOdul dazu gestellt werden muss.

Wie auch immer, ich habe alles so vorbereitet:

Code Auswählen Erweitern

defmod PM_KG_Waschmaschine MQTT_DEVICE
attr PM_KG_Waschmaschine IODev mqtt
attr PM_KG_Waschmaschine subscribeReading_data shelly_kg_waschmaschine/status/pm1:0
attr PM_KG_Waschmaschine userReadings dummy {json2reading($defs{$name},ReadingsVal($name, "data", "{}"),"",undef,"","apower")}
Im Data Reading steht folgendes drin:

Code Auswählen Erweitern

{"id":0, "voltage":235.4, "current":0.000, "apower":0.0 ,"freq":50.0,"aenergy":{"total":0.000,"by_minute":[0.000,0.000,0.000],"minute_ts":1715065259},"ret_aenergy":{"total":0.000,"by_minute":[0.000,0.000,0.000],"minute_ts":1715065259}}
Der json2reading Aufruf funktioniert bestens in der Commandline, im Userreading kommt aber folgdener Fehler:

Code Auswählen Erweitern

Error evaluating PM_KG_Waschmaschine userReading dummy: syntax error at (eval 300068076) line 1, at EOF
Missing right curly or square bracket at (eval 300068076) line 1, at end of line
Ich habe keine Ahnung wo da eine schließende Klammer fehlen soll. Kann mir jemand einen Tipp geben? Oder kann man "json2reading" eventuell besser im MQTT-Device einbauen?

#4

Einplatinencomputer / Aw: GPIO Bookworm

Letzter Beitrag von Wernieman - 07 Mai 2024, 09:02:11

Die Logmeldung könntest Du wegbekommen, in dem Du die Devices zu Dummys migrierst ....

#5

MQTT / Aw: Abfrage von Fahrzeugwerten...

Letzter Beitrag von Beta-User - 07 Mai 2024, 08:54:26

Die get Befehle triggerst Du dann mit einem Timer Deiner Wahl.

Da hier anscheinend "nur" minütliche Abfragen gebraucht werden, ginge es auch intern mit "periodicCmd". (Alles in einem Device, wäre einfacher in attrTemplate zu pflegen...)

Was noch interessant wäre, ist ein Ansatz für die Kommunikation mit zwei TX/RX Abfragen.

Man kann sowohl bei periodicCmd Perl verwenden (und z.B. einfach keine Abfrage machen, wenn offline usw.) wie auch in der readingList neben/vor der Rückgabe von Readings auch weitere Abfragen realisieren (ggf. iVm. dem FHEM-internen Each()).

Vielleicht auch gleich ein passendes pm-Modul.

Fände ich zumindest auf den ersten Blick auch gut. Du kannst das ggf. auch direkt selbst im "contrib"-Zweig zu attrTemplate selbst einchecken, da stehen noch ein paar mehr solcher myUtils-Dateien, die schlicht bei Bedarf über attrTemplate nachgeladen werden. Falls dazu Fragen sind: bitte melden.

#6

MQTT / Aw: Shelly 1 mini Gen3 mit MQT...

Letzter Beitrag von Beta-User - 07 Mai 2024, 08:39:49

lt. Template (Shelly1) wäre dies

Das scheinen "plus"-kompatible Geräte zu sein, von daher sollten eher die für die 2nd gen. gedachten templates passen. Da sich hier aber die wenigsten an https://forum.fhem.de/index.php?topic=112327.0 halten, ist es schwer, irgendwas dazu zu sagen oder den attrTemplate-Satz aufzubohren, damit er an den (unveränderten!) Topics erkennen kann, was ggf. paßt...

#7

MQTT / Aw: Readings als JSON formatie...

Letzter Beitrag von Beta-User - 07 Mai 2024, 08:31:58

klappt das genau so wie gewünscht

Du solltest dir ggf. mal ansehen, ob die Häufigkeit des Sendens auch so klappt wie gedacht .

Falls es zu viel ist: ggf. einfach nur (vermeintlich) das letzte durch das bulk-update (nehme ich zumindest an, dass die Readings per bulk befüllt werden) aktualisierte Reading "versenden" (also eigentlich: als trigger für den Code innerhalb MGB verwenden).

PS @tbk: Da dein Problem zwar ähnlich ist, aber doch anders und der eigentliche TE sein Problem gelöst hatte (aber nicht als solches markiert...), wäre es m.E. besser gewesen, einen neuen Thread aufzumachen und ggf. hierauf zu verweisen.

[Revision 28845: controls_fhem.txt: fhemupdate checkin]

#8

FHEM Code changes / Revision 28845: controls_fhem....

Letzter Beitrag von System - 07 Mai 2024, 08:30:59

Revision 28845: controls_fhem.txt: fhemupdate checkin

controls_fhem.txt: fhemupdate checkin

Source: Revision 28845: controls_fhem.txt: fhemupdate checkin

#9

MQTT / Aw: Umstellen vom FHEM-interne...

Letzter Beitrag von Beta-User - 07 Mai 2024, 08:25:00

Muss ich für jede MQTT2_DEVICE-Instanz irgendetwas in dem MQTT2_CLIENT konfiguriren?

....kommt darauf an...

Man muss ein paar Dinge beachten:
- das IODev muss v.a. bei den MQTT2_DEVICE (M2D)-Instanzen auf den MQTT2_CLIENT (M2C) zeigen, sonst kommen die Befehle nicht an (da ggf. versucht wird, über das alte IO zu versenden).
- Die subscriptions des M2C müssen passen. Da du "nichts" gesetzt hast, ist das hier "alles", was uU. (viel) zu viel ist, aber dafür sorgen sollte, dass deine M2D alle "beliefert" werden. Kann man auch "besser" machen, ist aber Aufwand. Ich würde in jedem Fall mal das Wiki zu M2C bemühen, v.a. auch zum Thema "ignoreRegexp".

#10

Hard- und Firmware / Aw: Firmware zu CUL, CUNX und ...

Letzter Beitrag von yersinia - 07 Mai 2024, 08:15:12

Werde ich beobachten und mich dann hier wieder melden. Für den nano am pi habe ich es umgesetzt, für den via ser2net an OpenWRT angebundenen muss ich schauen, da es nicht funktioniert hat (und stty ist dort auch nicht vorhanden; muss mich erst einmal belesen, wie der Treiber kmod-usb-serial-ftdi das dort eigtl umsetzt).

Eine udev rule benötige ich nicht, da es zuverlässig über serial/by-id/ funktioniert; der OpenWRT hat nur einen USB-port