Nachbau Energiezähler HM-ES-TX-WM

[real_Napster]

Hmm.. Jetzt hat es gute 5 Stunden problemlos funktioniert und seit 19 Uhr dann plötzlich kein Empfang mehr. Gerätekommunikation gestört.
Neustart des Geräts ohne Besserung
Muss ich morgen nochmal Debuggen ob er was sinnvolles ausspuckt. Am Standort habe ich nichts geändert.

EDIT:
Habe nun die Frequenz per "FreqTest" Sketch angepasst, mal sehen ob es heute Nacht jetzt stabil bleibt

[michaelapp]

Da mein Sensor in der Garage keinen Empfang hat, hab ich mir eine CCU2 zugelegt und sie als Gateway konfiguriert.

CCU2_2.jpg (19.3 KiB) 788 mal betrachtet

Leider schickt der HM-ES-TX-WM nichts weg, wenn ich mit dem HM-ES-TX-WM wieder in die Richtung CCU3 gehe funktioniert es.

Muss ich noch irgendwas konfigurieren?

Gruß
Michael

[chianti2000]

Mal eine andere Frage, der Zähler sendet ja laut Skript normalerweise aller 3 min (3*60) zur CCU.
Kann man den Sendezyklus auch verkürzen, ohne dass sich dann bei der Zählung etwas ändert, weil es eventuell einen mit der Abfragedauer verknüpften Faktor gibt?
Hintergrund ist, dass ich den Zähler zusätzlich auch als indirekten Leckagewächter nutzen möchte. Also per Skript eine Meldung aufs Handy, wenn sich der Zählerstand in einem Zeitraum ändert, wo eigentlich kein Wasser fließen sollte.

[HMSteve]

So kann ich mit meinem "Hichi"-Lesekopf am Lepus-Zaehler SMLs mitschneiden, in denen per Hand zumindest der Zaehlerstand in 0.1Wh zu finden ist. Im naechsten Schritt waere also der Code zu analysieren, warum er auch bei mir nur die gleichen Fehler der Art

Code: Alles auswählen

[parseMeterReading] SML_ERROR: entry = 5, type = 00

liefert.

Zur Dokumentation, falls noch jemand mit diesem Lepus-Zaehler darueber stolpert: Drei Anpassungen waren noetig, wenn der Zaehler per Pin freigeschaltet ist:

1. Message buffer vergroessern (Laeuft bei mir zum Test mit 700 byte, Message ist gut 650 byte gross. 700 byte ist schon viel fuer den 328p und verursacht womoeglich in bestimmten Konstellationen Probleme.) https://github.com/novag/HM-ES-TX-WM/bl ... WM.ino#L27
2. Typpruefung des Zaehlerstandes von signed auf unsigned int anpassen https://github.com/novag/HM-ES-TX-WM/bl ... M.ino#L392
3. Laenge des Leistungswertes von 32 Bit auf 64 Bit anpassen https://github.com/novag/HM-ES-TX-WM/bl ... #L468-L477

Eine laufende Version fuer diesen Zaehler findet sich unter https://github.com/HMSteve/HM-ES-TX-WM

Ist der Zaheler nicht freigeschaltet, liefert er weniger Daten, konkret zwar den Zaehlerstand, aber nicht die Leistung. Dann genuegt der 500 byte Puffer.

Viele Gruesse,
Stephan

[HMSteve]

Mal eine andere Frage, der Zähler sendet ja laut Skript normalerweise aller 3 min (3*60) zur CCU.
Kann man den Sendezyklus auch verkürzen, ohne dass sich dann bei der Zählung etwas ändert, weil es eventuell einen mit der Abfragedauer verknüpften Faktor gibt?
Hintergrund ist, dass ich den Zähler zusätzlich auch als indirekten Leckagewächter nutzen möchte. Also per Skript eine Meldung aufs Handy, wenn sich der Zählerstand in einem Zeitraum ändert, wo eigentlich kein Wasser fließen sollte.

Hallo Gerd,

wenn ich nichts uebersehen habe, wird im Sketch an den beiden relevanten Stellen der MSG_CYCLE beruecksichtigt, sollte also moeglich sein, einfach nur hier anzupassen: https://github.com/jp112sdl/Beispiel_As ... CU.ino#L28

Viele Gruesse,
Stephan

[jp112sdl]

sollte also moeglich sein, einfach nur hier anzupassen

Aber am besten nur für den Fall, wenn sich der Zählwert auch ändert und nicht penetrant permanent alle paar Sekunden stumpf senden (Paket-Kollisionen mit anderen Geräten).

[chianti2000]

Die Anpassung an der von HMSteve bezeichneten Stelle funktioniert.
Ich hab statt 3 min (3x60) nunmehr 1 min (1x60) eingestellt und konnte keine Verfälschung der Zählwerte feststellen.

Aber am besten nur für den Fall, wenn sich der Zählwert auch ändert und nicht penetrant permanent alle paar Sekunden stumpf senden (Paket-Kollisionen mit anderen Geräten).

@Jérôme
Das ist richtig, leider habe ich keine Ahnung was man da im Skript ändern muss.

[HMSteve]

Habe folgendes Problem mit dem device: Es sind ja zwei Kanaele definiert, daher wollte ich den zweiten fuer die eingespeiste Energie nutzen und habe ihn analog dem ersten an die sysclock gehaengt: https://github.com/HMSteve/HM-ES-TX-WM/ ... #L591-L592. Dann das Geraet an die ccu angelernt. Es sendet nun mit https://github.com/HMSteve/HM-ES-TX-WM/ ... #L294-L300 die erwarteten peer event messages von Kanal 1 an die CCU:

Code: Alles auswählen

<- 15 00 A2 60 F81501 BA4BC3 01 00 00 00 20 FC 92 00 00 00 DE 44

Es folgen allerdings von Kanal 2 jeweils 2x6 mit Burst gesendete Nachrichten an Broadcastadressen, hier jeweils eine der sechs:

Code: Alles auswählen

<- 15 00 B2 60 F81501 0000FF 02 00 00 00 01 D2 36 00 00 00 00 00
<- 15 00 B2 60 F81501 FFFFFF 02 00 00 00 01 D2 36 00 00 00 00 00

Geht das also gar nicht wie gedacht mit den zwei Kanaelen, oder was mache ich falsch?

Danke und viele Gruesse,
Stephan

[jp112sdl]

Werks-Reset & neu anlernen nach dem Ändern auf 2 Kanäle hast du schon gemacht?

Wie sieht die EEPROM-Belegung beim Booten im seriellen Monitor aus?
Address Space 32... ???

[HMSteve]

Werks-Reset & neu anlernen nach dem Ändern auf 2 Kanäle hast du schon gemacht?

Wie sieht die EEPROM-Belegung beim Booten im seriellen Monitor aus?
Address Space 32... ???

Keine Ahnung, was gestern schief lief, hatte sogar den EEPROM manuell geloescht, weil Werksreset nicht half. Heute nochmal Werksreset, und es laeuft, wie es soll (je Kanal eine message an die ccu).

Falls es jemand braucht, habe noch einen CRC unter Nutzung der FastCRC lib eingebaut, da zumindest mein meinem setup recht viele korrupte messages vom Lesekopf kommen. Sketch siehe https://github.com/HMSteve/HM-ES-TX-WM ... -TX-WM.ino.