Alternative Methode zum Auslesen von Zählern (Wasseruhr, Gaszähler etc)

Begonnen von eki, 02 November 2020, 17:25:39

Vorheriges Thema - Nächstes Thema

Benni

Zitat von: majestro84 am 22 Dezember 2021, 16:20:19
was nutzt Ihr den so für Längen der Rohre?
Also wie ist der Abstand bei euch?

Habe gerade mal kurz nachgeschaut: Der Abstand zw. Kameralinse und Wasseruhr (Glas) beträgt bei mir in etwa 10cm.

gb#

KurtK

Zitat von: majestro84 am 22 Dezember 2021, 16:20:19
Hallo zusammen,

was nutzt Ihr den so für Längen der Rohre?
Also wie ist der Abstand bei euch?

VG Alex

Ich nutze zwar kein HT Rohr sondern habe mir was passendes gedruckt, aber Länge von den Einkerbungen der Wasseruhr bis zur Kameralinse sind 12cm, von der Scheibe des Zählers gemessen sind es dann ca. 9cm.
- FHEM auf Intel NUC mit Proxmox -
- FTUI mit FUIP -
- HM, Zigbee,  WLAN -

andy19850

Als ich innerlich schon mit der Erfassung des Wasserzählers abgeschlossen hatte, bin ich auf das Projekt gestoßen. Also, Sachen bestellt und los.

Funktioniert bis auf kleinere Details auch prima.

Ich scheitere aber an einer fundamentalen Sachen: MQTT. Ich habe einen Broker über Mosquitto im Docker-Container laufen. Alle Geräte (Shellies, Gosund etc.) verbinden sich anstandslos und haben sich automatisch angelegt.
Nur dieser Wasserzähler nicht.
Das FHEM-Log meldet:
1:  json2namevalue: Error parsing >NNNNN.465,"error":"","rate":0.000000,"timestamp":""< for prefix/name:value

Über den MQTT-Explorer sehe ich die Werte des Wasserzählers. Autocreate ist auf "simple" gestellt.
Wer kann mir auf die Sprünge helfen?

PS: Ich weiß, NNNNN ist nicht gut. Da muss ich nochmal in der Ausrichtung nachbessern

Beta-User

Zitat von: andy19850 am 23 Dezember 2021, 14:12:40
1:  json2namevalue: Error parsing >NNNNN.465,"error":"","rate":0.000000,"timestamp":""< for prefix/name:value
Das sieht danach aus, also würde das Element im JSON ohne Quotes übermittelt, was eigentlich nur für Zahlen vorgesehen ist. Falls es möglich ist, müßtest du mal versuchen, den ganzen JSON-Blob abzugreifen, damit man das nachstellen kann, ansonsten halte ich es für einen Bug der firmware, wenn (hier) unzulässigerweise keine Quotes gesetzt werden, obwohl kein Zahlenwert übergeben wird.

(Etwas mehr Infos zum verwendeten Modul wären auch hilfreich, ich vermute MQTT2_DEVICE?).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

andy19850

Genau MQTT2_Device, sorry!

{"value":NNNNN.454,"error":"","rate":0.000000,"timestamp":""}

Der MQTT Explorer meldet das als json.

Beta-User

...es entspricht aber leider nicht der JSON-spec (oder dem, was ich aus diesem Link ableite: https://forum.fhem.de/index.php/topic,108080.msg1181123.html#msg1181123)...

Mal angenommen, dein Device heißt "Dummy", dann wirft die erste Variante einen/den Fehler, die zweite geht (jeweils via FHEM-Kommandofeld)...
{ json2reading($defs{Dummy},'{"value":NNNNN.454,"error":"","rate":0.000000,"timestamp":""}' )}
{ json2reading($defs{Dummy},'{"value":"NNNNN.454","error":"","rate":0.000000,"timestamp":""}' )}

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

frober

Zitat von: andy19850 am 23 Dezember 2021, 14:12:40
PS: Ich weiß, NNNNN ist nicht gut. Da muss ich nochmal in der Ausrichtung nachbessern

Mache das mal zuerst, dann werden auch Zahlen übertragen. Wenn dann noch ein Problem.ist, kannst du weiter suchen.
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...

andy19850

Habe ich getan. Keine Fehlermeldung im Log, aber auch kein neues Device...

Json:
{"value":774.246,"error":"Rate too high - Read: 774.574 - Pre: 774.246","rate":0.000000,"timestamp":""}

btw...was bedeutet Rate too high?

frober

Ist das der erste Wert, der gesendet wurde, dann behaupte ich mal, dass die Differenz der Änderung zu Null zu hoch ist.

Ich lese nur mit, momentan habe ich noch keine Verwendung für diese Methode.

MQTT2_Client, hmm. Ich weiß nur, dass es keine eindeutige ID  diesem Fall gibt, wodurch die Geräte unterschieden werden. Wie sich das auswirkt, keine Ahnung.

Hast du mal probiert manuell anzulegen?
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...

andy19850

Manuell habe ich es noch nicht versucht. Magst du mir einen Denkanstoß geben, wie ich das bewerkstelligen kann?

frober

Zitat von: andy19850 am 24 Dezember 2021, 09:27:21
Manuell habe ich es noch nicht versucht. Magst du mir einen Denkanstoß geben, wie ich das bewerkstelligen kann?

https://fhem.de/commandref.html#MQTT2_CLIENT
https://wiki.fhem.de/wiki/MQTT2_CLIENT

Edit: Links korrigiert, versehentlich auf das alte MQTT verwiesen ::)

Ich habe das früher nur mit den "alten" MQTT + Mosquitto gemacht.
Falls du nicht zurecht kommst, mache einen neue Thread im richtigen Unterforum auf.

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...

Beta-User

Zitat von: frober am 24 Dezember 2021, 10:20:06
Ich habe das früher nur mit den "alten" MQTT + Mosquitto gemacht.
Falls du nicht zurecht kommst, mache einen neue Thread im richtigen Unterforum auf.
Meine Güte, nur weil sich der Sensor zurecht beschwert, dass der ermittelte Wert zu weit vom alten (0) abweicht, muss man doch nicht gleich alles mögliche in die Luft werfen...

Einfach erst mal einen sauberen Alt-Wert in die firmware werfen, und wenn es dann mit MQTT2_CLIENT nicht klappen will, ggf. auf MQTT2_SERVER wechseln (anderer Port).

Für JSON-Payloads ist MQTT_DEVICE einfach outdated, und wenn es um's Senden von JSON geht, ist es einfach nicht mehr zu empfehlen. Also sollten sich Einsteiger damit nicht befassen, und manuelles Anlegen geht mit MQTT2_DEVICE zwar anders, aber im Prinzip dann doch ganz ähnlich...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

frober

Zitat von: Beta-User am 24 Dezember 2021, 10:54:09
Meine Güte, nur weil sich der Sensor zurecht beschwert, dass der ermittelte Wert zu weit vom alten (0) abweicht, muss man doch nicht gleich alles mögliche in die Luft werfen...

Einfach erst mal einen sauberen Alt-Wert in die firmware werfen, und wenn es dann mit MQTT2_CLIENT nicht klappen will, ggf. auf MQTT2_SERVER wechseln (anderer Port).

Für JSON-Payloads ist MQTT_DEVICE einfach outdated, und wenn es um's Senden von JSON geht, ist es einfach nicht mehr zu empfehlen. Also sollten sich Einsteiger damit nicht befassen, und manuelles Anlegen geht mit MQTT2_DEVICE zwar anders, aber im Prinzip dann doch ganz ähnlich...

Das waren eigentlich zwei Themen oder meinst du, das die Beschwerde den Autocreate verhindert?

Oh F..ck, das war nicht meine Absicht, die Links weisen auf die MQTT nicht auf MQTT2, sorry.
P.S. habe es korrigiert
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...

Beta-User

Na ja, wenn was gesendet wird, sollte auch was angelegt werden. Da wir aber weder wissen, ob TYPE=autocreate aktiv ist, noch, ob es ein "Sammeldevice" gibt, in dem die Werte gelandet sind, macht jedenfalls das Wechseln der Pferde m.E. wenig Sinn....
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

frober

Autocreate simple hatte er geschrieben, ich gehe davon aus, das es auch noch gesetzt ist.

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...