ESPHome, wie im ersten Post beschrieben
BTW- batteriesparender wird die (regelmäßige)Abfrage über M-Bus sicher auch nicht sein, oder?
Vielleicht ist das der Grund, warum die Stadtwerke das versuchen zu verhindern.
Wie lange läuft es jetzt über IR bei euch ohne Unterbrechung?
Mein Zähler ist heute Morgen nach ca 30h ausgestiegen.
Nach abnehmen/auflegen sendet er nun wieder.
Glaube das ist eher besser für die Batterie, da der Zähler ja sowieso dauerhaft sendet.
Wenn die Stadtwerke vorbei fahren, „fangen“ sie die Daten damit ein.
(Beitrag vom Verfasser gelöscht)
Ich habe mich nochmals an Kamstrup gewendet. Zwei interessante Infos aus der Antwort möchte ich mit euch teilen:
- Wir möchten klarstellen, dass Kamstrup “Individual Keys” und keine “Common Keys” zur Verschlüsselung der Wireless M-Bus Kommunikation verwendet. Jeder Zähler hat seinen eigenen Verschlüsselungsschlüssel, es ist nicht möglich, auch andere Zähler auszulesen.
Damit werde ich nochmal meinen Wasserversorger konfrontieren.
- Es gäbt auch die Möglichkeit, einen Impulsleser von Kamstrup zu verwenden.
Update:
Dieser Adapter würde funktionieren. Mit 166€ kein Schnapper.
Vielleicht kann man sowas nachbauen. Ich kann es leider nicht
by HarryP: Zusammenführung Doppelpost (bei Änderungen oder hinzufügen von Inhalten bitte die „Bearbeitungsfunktion“ anstatt „Antworten“ zu nutzen)
Ich habe das Problem der Abbrüche dadurch gelöst von 120 auf 100 Sekunden zu gehen. Seitdem läuft die Verbindung stabil.
120 Sekunden scheint der timeout zu sein und je nach Geschwindigkeit der Abfrage manchmal um einen Moment zu früh zu terminieren.
Danke, das werde ich auch mal testen.
Im Moment habe ich einen Restart im Script nach 24h. Aber es läuft noch nicht lange genug, um sagen zu können, ob es funktioniert.
Da ich das Problem mit dem Verbindungsabbruch nach 12 Stunden habe, liegt der Impulsadapter hier schon eine Weile auf dem Tisch:
Bisherige Ergebnisse nach 2 Abenden:
- Die Positionierung und Ausrichtung des Magneten ist deutlich anders als erwartet. Oder nur für diesen Einsatzzweck extra so? Die Aktivierung der IR Schnittstele funktioniert so aber sehr zuverlässig! Maße, Position und Ausrichtung des Magneten muss ich nochmal dokumentiern.
Der Magnet ist 10mm. An der auf dem Bild zu sehenden Stelle funktioniert die Aktivierung sehr gut, bereits aus einigen mm Entfernung.
- Ich habe den originalen Pulse Adapter für flowIQ 2200/3200 getestet. Nach Aktivierung per Tastendruck gibt er wie erwartet 1 Puls pro 10 Liter aus.
Das optische Aktivierungssignal konnte ich mehrfach mitschneiden. Es ist dekodierbar als:
1200 Baud, 8N2
80 3F 02 35 E9
Beispiel:
MODE=1200_8N2 NORMAL OFFSET=0 HEX=80 3F 02 35 E9 GOOD=5/5
Der WattWächter-RX kann dieses Signal sauber empfangen. Was bisher nicht klappt: Das Signal mit dem WattWächter/ESPHome selbst so nachzusenden, dass der flowIQ dadurch aktiviert wird.
Meine Vermutung: Es liegt weniger am Byteinhalt, sondern eher an Optik/Timing/Positionierung, z. B. TX-Leistung, Streulicht, Abstand, Winkel oder Magnetposition.
Offene Fragen:
-
Hat jemand den Pulse Adapter 66-99-051 schon einmal erfolgreich nachgebaut?
-
Ist
80 3F 02 35 E9als Aktivierungsbefehl bekannt? -
Gibt es besondere Anforderungen an Timing, IR-Leistung oder optische Positionierung?
-
Wie könnte man sinnvoll zwischen Originaladapter und Zähler optisch mitsniffen?
Von meinem Versorger kam auch nur dies:
Aus grundsätzlichen Erwägungen können wir Ihnen den Schlüssel leider nicht zur Verfügung stellen.
Hintergrund ist, dass mit diesem Schlüssel auch Änderungen am Zähler vorgenommen werden könnten. Das liegt selbstverständlich nicht in unserem Interesse.
Nach Auskunft der Firma Kamstrup könnte es hierfür möglicherweise eine technische Lösung geben. Diese wird von uns derzeit jedoch nicht angeboten; auch zu den damit verbundenen Kosten liegen uns keine Informationen vor.
Wäre interessant zu wissen:
-
Ob das mit den Kosten stimmt, oder die nur nicht wollen oder wissen, wie es geht.
-
Gibt es 2 Schlüssel, einen der lesen und schreiben und einen der nur lesen kann?
(Beitrag vom Verfasser gelöscht)
Hast du mal versucht, dein Abfrageintervall auf 100 sek zu setzen?
Bei mir läuft mit 120 sek der Zähler für ca 30h, danach schläft er ein.
Nachdem ich einen Neustart in Script nach 24h drin habe, läuft er inzwischen seit 40h durch.
Ich habe alles erdenkliche getestet. Nach 12 Stunden war bei mir immer Schluss.
Meine Vermutung ist, dass es an der FW oder Konfiguration des Versorgers liegt.
Wie setzt du das mit dem Neustart um?
Es schläft also dein ESP ein?
Nein, aber scheinbar wird durch den Neustart des ESP dem Zähler signalisiert, dass es sich um eine neue Abfrage handelt.
Ich habe aber gerade nochmal nachgeschaut, bei mir ist das Abfrageintervall auf 60sek. (Also das vom Zähler)
esphome:
name: flowiq-2200
friendly_name: flowIQ 2200
esp8266:
board: esp01_1m
logger:
baud_rate: 0
api:
encryption:
key: "key"
ota:
- platform: esphome
password: "PW"
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
ap:
ssid: "Flowiq-2200 Fallback Hotspot"
password: "12345678"
uart:
baud_rate: 1200
stop_bits: 2 # Kamstrup benötigt zwingend 2 Stopbits!
tx_pin: GPIO1 # Standard-Pins des WattWächters
rx_pin: GPIO3
rx_buffer_size: 512
sensor:
- platform: kamstrup_kmp
id: kamstrup_live
update_interval: 60s
custom:
- name: Volume
command: 0x0044 # Register für den Gesamtzählerstand
unit_of_measurement: "m³"
accuracy_decimals: 5
state_class: "total_increasing"
device_class: "water"
- name: Battery days left
id: battery_days
command: 0x0246 # Register für die verbleibenden Batterietage
unit_of_measurement: "days"
accuracy_decimals: 1
# Berechnet die Batterie-Restlaufzeit zusätzlich in Jahren und Prozent
- platform: copy
source_id: battery_days
name: "Battery lifetime percent"
unit_of_measurement: "%"
accuracy_decimals: 1
filters:
- lambda: return (x / (16.0 * 365.0)) * 100.0;
- platform: copy
source_id: battery_days
name: "Battery lifetime decimal years"
unit_of_measurement: "a"
accuracy_decimals: 2
filters:
- lambda: return x / 365.0;
# SICHERER REBOOT-AUTOMATISMUS (Umgeht die 36h-Kamstrup-Sperre)
# Startet den ESP nach exakt 24 Stunden kontinuierlicher Laufzeit neu.
- platform: uptime
name: "Diag : Uptime"
id: esp_uptime
update_interval: 60s
on_raw_value:
then:
- lambda: |-
if (x > 86400.0) {
id(reboot_button).press();
}
text_sensor:
- platform: template
name: "Battery lifetime Y/M/D"
update_interval: 60s
lambda: |-
if (isnan(id(battery_days).state) || id(battery_days).state < 0) return {"unknown"};
int total_days = (int) roundf(id(battery_days).state);
int years = total_days / 365;
int rem_days = total_days % 365;
int months = rem_days / 30;
int days = rem_days % 30;
char buffer[32];
sprintf(buffer, "%dJ %dM %dT", years, months, days);
return {buffer};
button:
- platform: restart
name: "Ctrl : Device Restart"
id: reboot_button
1 „Gefällt mir“
Seit letzten Freitag läuft es nun durch. Die Daten kommen regelmäßig rein und stimmen mit dem Stand am Zähler überein.
Ich bin zufrieden. So gibt es (für mich) keinen Grund, auf eine andere Lösung zu schielen.
Wenn ich jetzt überraschenderweise den AES Key doch noch bekäme, würde ich es trotzdem nicht ändern.
Habe jetzt mehrere Wochen stabile Daten bei Anfrage alle 100 Sekunden
Meine Batterie soll aktuell noch 13 Jahre, 1 Monat und 19 Tage halten. Das habe ich auf ein Datum umgerecht mit einer Automation, die mich benachrichtigt, wenn sich das Datum ändert.
Ab und zu springt es zwischen 22.8.2039 und 21.8.2039, ist aber ansonsten stabil.
Wie sieht das bei euch aus?
Und werdet ihr den Leser entfernen, wenn sich der Wasserversorger ankündigt?
Mir auch egal wenn er nach 8 Jahren leer ist.
Wenn sie keine Zugangsdaten hergeben haben sie eben Pech.
der Versorger sollte ja nicht mehr kommen weil fernablesbar.
Der Zähler ist ja Eigentum des Versorgers. Ich weiß nicht, ob man rechtlich ein Problem bekommen kann.
Das Auslesen über M-Bus ist sicher auch nicht stromsparender, wenn man es im Minutentakt macht…
Werde das nun auch testen. Werde berichten.
Falls sich der Versorger mal ankündigen sollte, würde ich es schnell abbauen. Ist ja kein Akt. Da der Versorger ja nicht kompetent genug ist, den Code rauszurücken, bezweifle ich, dass er irgendwie merkt, dass ich per IR Auslese.
Sehe das alles extrem entspannt.
Im Zweifelsfall wenn die Batterie den Geist aufgibt, kontaktiere ich den Versorger und bemängele, dass ich aus irgend einem Grund nicht mehr ablesen kann. Dann werden die den Zähler tauschen. Hatte ich wirklich schon mal ohne Zutun, da ging die Anzeige nicht mehr. Zähler wurde direkt getauscht.
Ich verzweifle hier leider. Habe auch alles nach Anleitung gemacht. Bekomme auch den Folgenden Fehler:
[20:36:31.657][VV][api.service:013]: }
[20:36:34.739][E][kamstrup_kmp:171]: Received invalid message (prefix mismatch received 0x80, expected 0x40)
[20:36:34.741][E][kamstrup_kmp:194]: Received invalid message (CRC mismatch)
[20:36:34.741][E][kamstrup_kmp:171]: Received invalid message (prefix mismatch received 0x80, expected 0x40)
[20:36:34.741][E][kamstrup_kmp:171]: Received invalid message (prefix mismatch received 0x3F, expected 0x40)
Selbst das Abkleben wie auf dem Bild hilft aber nicht. Entweder kommt der Fehler weiterhin oder irgendwann sagt er, dass keine Verbindung möglich ist.
jemand eine Idee?
+++ UPDATE +++
Habs gelöst, indem ich den Update-Intervall zum Testen auf 5s gestellt hab und den Log parallel laufen lassen. Die finale Einstellung ist Millimeterarbeit, dann kamen aber Daten. Panzertape sorgt für den Halt 
Läuft seit mehr als 36 Stunden ohne Abbrüche. Habe auch das Neustart-Script eingebaut und der Abfrageintervall steht auf 60s
1 „Gefällt mir“