neues Modul 98_readingsWatcher , war 98_ReadingsSupervision

Begonnen von Wzut, 15 Februar 2016, 20:49:53

Vorheriges Thema - Nächstes Thema

Florian_GT

Hiho,

in der Anleitung muss was angepasst werden:
readingActifity (default none)
Das Modul kann ähnlich dem HomeMatic ActionDetector im überwachten Gerät ein eigenes Reading setzen und den Überwachungsstatus
in diesem speichern. Beispiel :
attr <name> readingActifity actifity
Erzeugt in den überwachten Geräten das zusäzliche Reading actifity und versorgt es mit dem Status dead bzw alive
attr <name> readingActifity aktiv:0:1
Erzeugt in den überwachten Geräten das zusätzliche Reading aktiv und versorgt es mit dem Status 0 bzw 1


Statt readingActifity muss es readingActivity sein!

Gruß Florian
FHEM: Proxmox Server, FHEM in VM, pgSQL DB
Hardware: Ethersex (Pollin NETIO Boards), Diverse Tasmota MQTT Devices, Raspberry Pi Zero W Kameras, (Github RaspberryPiStreamingCamera), Zigbee2MQTT, ESPEasy

Development: UBA (Umwelt Bundesamt), BFS (Bundesamt für Strahlenschutz)

dirk.k

Hallo zusammen,
ein Feature-Wunsch ...
ich nutze readingsWatcher nun schon lange und für einen Haufen Geräte.
Nun kommt es immer wieder vor, dass Geräte geplant längere Zeit nicht anwesend oder im Einsatz sind.
Es wäre toll, diese Geräte für readingsWatcher pausieren zu können, als sie die ganze Zeit in der Liste der ausgefallenen zu haben.
Genial wäre es, wenn der gesetzte "pausiert" Status verschwindet, wenn das Gerät wieder "alive" meldet.
Was haltet ihr davon?
   

Wzut

Zitat von: Florian_GT am 03 Oktober 2021, 02:23:14
Statt readingActifity muss es readingActivity sein!
THX4Info, werde ich bei Gelegenheit fixen.

Zitat von: dirk.k am 06 Oktober 2021, 19:09:40
Es wäre toll, diese Geräte für readingsWatcher pausieren zu können
Ist schon drin wenn beim entsprechenden Device dessen Attribut disable oder ignore auf 1 gesetzt ist.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Beta-User

...da ich grade eh' dabei war, commandref-"id"-Vorschläge zu verteilen, hier einer für readingsWatcher :) .

Da das zentrale Attribut ja ein dezentrales ist, ist die eigentliche Modulbeschreibung jetzt halt verkürzt und der Teil in die Attributbeschreibung gewandert. Hoffe, es gefällt :) .



Eine funktionale Frage hätte ich noch: Ich würde gerne ein "totes" Reading ganz löschen. Dazu steht aber nichts in der commandref. Ohne jetzt hier bzw. dem Entwiicklungsthread dazu intensiv gesucht zu haben: Geht das?
Oder könnte man das ggf. (via Schlüsselwort "undef" (?)) ergänzen?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Wzut

Zitat von: Beta-User am 29 Januar 2022, 07:14:07
commandref-"id"-Vorschläge zu verteilen
--snipp---
Ich würde gerne ein "totes" Reading ganz löschen.
a. verstehe im Moment nicht um was es genau geht schaue mir deine Datei heute Mittag mal an.
b. um Readings aufzuräumen : set <name> clearReadings - alles was noch gebraucht wird kommt dann es im nächsten Lauf wieder
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Beta-User

Zitat von: Wzut am 29 Januar 2022, 09:24:37
a. verstehe im Moment nicht um was es genau geht schaue mir deine Datei heute Mittag mal an.
Na ja, zum einen ist "id" (statt "name") der neue (allgemeine) "Standard" bei der Identifizierung/Belabelung der Ankernamen in der commandref, zum anderen (und das ist hier der springende Punkt) erlaubt es eine bestimmte Benennung iVm. der Klarstellung, zu welchem Modul (z.B.) ein Attribut gehört, dann auch eine entsprechende Sortierung bei den Attributen allgemein und die Darstellung eines entsprechenden Hilfetextes. Siehe screenshot (das ist ausschnittsweise ein MQTT2_DEVICE). Gibt auch einen recht aktuellen Thread dazu im Dev-Bereich.

Zitatb. um Readings aufzuräumen : set <name> clearReadings - alles was noch gebraucht wird kommt dann es im nächsten Lauf wieder
Es ging eher darum, das Reading jeweils am Ausgangsdevice zu löschen. Mein Anwendungsfall ist aber ein Sonderfall und mir ist zwischenzeitlich was anderes dazu eingefallen, da ist eh' ein Eventhandler dazwischen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Hi Wzut,

gibt es noch Fragen bzgl. der "id"-commandref?
Weitere Infos und links wären hier zu finden: https://forum.fhem.de/index.php/topic,125039.msg1206275.html#msg1206275
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Wzut

nöö schon gut , ich werde deinen Vorschlag nehmen und will aber noch wegen alias Unterstützung ein neues Attribut einbauen.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

ToJu

Hallo,

ist schon etwas her:
Zitat von: Wzut am 11 Januar 2020, 09:04:16
ok, ich habe es begriffen. Einfach gesagt :
a. wird an einem Device nur ein Reading überwacht -> alles wie bisher
b. bei mehr als einem Readings sollte der User entscheiden (mal schauen wie) ob die einzelen überwachten Readings als UND oder ODER den Gesamtstatus bilden.

Eine einfache Möglichkeit wäre z.B.
attr Thermo1 readingsWatcher 300,???,CUL_RSSI,CUL2_RSSI
heute, Readings werden als ODER behandelt
attr Thermo1 readingsWatcher 300,???,CUL_RSSI+CUL2_RSSI
neu , als UND

Leider steht dazu nichts in der Doku. Ist das im Code enthalten? Was bedeutet hier UND / ODER genau? Wenn ich zwei Readings angebe, dann habe ich hier Interpretationsmöglichkeiten:

ODER:

  • Gerät ist "dead" wenn eines oder das andere ausfällt?
  • Es wird als "alive" angesehen, wenn das eine oder das andere noch aktiv ist?

Grüße,
Torben

Panik

Hallo,

ich habe ein paar batteriebetriebene Temperatursensoren mit Readingswatcher überwacht.

Attribut für RS im Device: 3600,,temperature,humidity,dewpoint,batteryPercent
Attribut in RS attr <name> readingActivity actifity

Sobald die Batterie irgendwann leer ist, gibt es nach geraumer Zeit natürlich in dem
Device die Meldung bei  actifity "dead".

Das Log wird jedoch auch befüttert:
PERL WARNING: Argument "timeout" isn't numeric in numeric le (<=) at (eval 103242) line 1

Wie kann die Logmeldung verhindert werden, ohne das Device auf disabled zu stellen?
Raspberry3+,  CUL USB V3 mit V 1.66 CUL868, TRXRFX433, HM-MOD-UART, Phoscon-GW

Gisbert

Hallo Panik,

ich hab ein ähnliches Problem mit Tuya-Devices, die solche log-Einträge im Minutentakt erzeugen:
2023.05.03 22:38:08.867 1:  'setreading tuya_local_bf40c31ece6575958bzage active alive' called form userReadings is prohibitedIch weiß leider nicht, wo ich ansetzen muss, um das zu verhindern.

Mir kommt beim Schreiben dieses Beitrags ein Gedanke. Der log-Eintrag sagt ja aus, dass ich ein setreading nicht in einem userReading tun darf. Dann sollte ich den Rat befolgen und eine andere Lösung suchen.

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | tuya local | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY | DEYE | JK-BMS | ESPHome

frober

Zitat von: Panik am 15 Januar 2023, 08:14:32Hallo,

ich habe ein paar batteriebetriebene Temperatursensoren mit Readingswatcher überwacht.

Attribut für RS im Device: 3600,,temperature,humidity,dewpoint,batteryPercent
Attribut in RS attr <name> readingActivity actifity

Sobald die Batterie irgendwann leer ist, gibt es nach geraumer Zeit natürlich in dem
Device die Meldung bei  actifity "dead".

Das Log wird jedoch auch befüttert:
PERL WARNING: Argument "timeout" isn't numeric in numeric le (<=) at (eval 103242) line 1

Wie kann die Logmeldung verhindert werden, ohne das Device auf disabled zu stellen?

Naja, wenn man einen String 'timeout' wo hinschreibt, wo eine Zahl erwartet wird, kommt eine entsprechende Meldung.
D.h. die Weiterverarbeitung in dewpoint, SVG Plot, notify, Userreading....
Raspi 3b mit Raspbian Bullseye und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

Gisbert

Zitat von: Gisbert am 03 Mai 2023, 22:52:20Hallo Panik,

ich hab ein ähnliches Problem mit Tuya-Devices, die solche log-Einträge im Minutentakt erzeugen:
2023.05.03 22:38:08.867 1:  'setreading tuya_local_bf40c31ece6575958bzage active alive' called form userReadings is prohibitedIch weiß leider nicht, wo ich ansetzen muss, um das zu verhindern.

Mir kommt beim Schreiben dieses Beitrags ein Gedanke. Der log-Eintrag sagt ja aus, dass ich ein setreading nicht in einem userReading tun darf. Dann sollte ich den Rat befolgen und eine andere Lösung suchen.

Viele Grüße Gisbert

Leider zu früh gefreut.
Ich hab das ganze Konstrukt jetzt von einem userReading zum stateFormat verlagert, aber mit dem gleichen Ergebnis, dass sehr viele log-Einträge mit dem identischen Inhalt produziert werden.

Hier meine Definition des stateFormats meines Devices:
attr tuya_local_bf40c31ece6575958bzage stateFormat {if (ReadingsVal($name,'active','') eq "alive" or ReadingsVal($name,'state','') eq "alive" ) {"power: ".round(ReadingsVal($name,'cur_power',''),1)." W<br/>voltage: ".round(ReadingsVal($name,'cur_voltage',''),1)." V<br/>relay state: ".ReadingsVal($name,'state','')."<br/>device: ".ReadingsVal($name,'active','')} else {"device: ".ReadingsVal($name,'active','')}}Das Reading "active" wird durch den readingsWatcher erzeugt.

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | tuya local | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY | DEYE | JK-BMS | ESPHome

frober

Zitat von: Gisbert am 04 Mai 2023, 12:12:00Leider zu früh gefreut.
Ich hab das ganze Konstrukt jetzt von einem userReading zum stateFormat verlagert, aber mit dem gleichen Ergebnis, dass sehr viele log-Einträge mit dem identischen Inhalt produziert werden.

Hier meine Definition des stateFormats meines Devices:
attr tuya_local_bf40c31ece6575958bzage stateFormat {if (ReadingsVal($name,'active','') eq "alive" or ReadingsVal($name,'state','') eq "alive" ) {"power: ".round(ReadingsVal($name,'cur_power',''),1)." W<br/>voltage: ".round(ReadingsVal($name,'cur_voltage',''),1)." V<br/>relay state: ".ReadingsVal($name,'state','')."<br/>device: ".ReadingsVal($name,'active','')} else {"device: ".ReadingsVal($name,'active','')}}Das Reading "active" wird durch den readingsWatcher erzeugt.

Viele Grüße Gisbert


Ohne die entsprechenden Logeinträge kann ich nur Hellsehen.

Aber ReadingsVal und round() würde ich vermeiden.  Dafür gibt es ReadingsNum, der 4. Parameter ist für die Anzahl der Stellen.
Genauso eine Zahl auszulesen und den Defaultwert als String anzugeben, erzeugt irgendwann eine Perl Warnung beim Weiterverarbeiten der Daten (dazu zählt auch das Loggen und Anzeigen der Plots).
Das gilt auch für readingsWatcher, wenn ich einen String z.B. 'timeout' ins Reading einer Zahl schreibe, kann ich damit nicht rechnen. Ergo gibt es ein Logeintrag.
Raspi 3b mit Raspbian Bullseye und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

Gisbert

Hallo frober,

danke für deine Hinweise. Ich werde das prüfen und versuche deine Vorschläge umzusetzen.

Die log-Einträge kommen im Minutentakt, manchmal ist aber eine halbe Stunde kein log-Eintrag da. Anschließend geht es wieder im Minutentakt weiter.

2023.05.03 22:38:08.867 1:  'setreading tuya_local_bf40c31ece6575958bzage active alive' called form userReadings is prohibitedDer Eintrag kommt, egal ob ich das im userReading- oder stateFormat-Attribut definiert habe.

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | tuya local | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY | DEYE | JK-BMS | ESPHome