Wireless M-Bus für CUL

[mdewendt]

Hallo.

Der CUL868 ist da - es kommen wesentlich mehr Telegramme und Zähler rein als vorher.

Hier der manuf spec Part von einem Wasserzähler:
0c0008613000010613080bfffc


Martin

[kaihs]

Ist mbus senden eigentlich überhaupt im CUL implementiert?

Aktuell nicht. Sollte sich aber relativ einfach ergänzen lassen, der Code dafür ist prinzipiell schon vorhanden.

Fragt sich nur, was gesendet werden sollte. Die bisher empfangenen Pakete haben als C-Field ja alle 44 = Send, no response
Laut Standard erwarten sie also keine Antwort.

Mag jemand mal telefonisch bei Qundis anfragen? Dann müssen sie ja irgendeine Antwort geben.

[mdewendt]

Hallo.

Ärgerlich gerad wurden erst die Kaltwasserzähler getauscht da zu alt - da hätte  man sicherlich schon mitlesen können wie die Werte ausgelesen werden.
Irgendwo muss sich doch die Software finden lassen für die Hausverwaltungen die das Zählerauslesen übernehmen. Ansonsten bleibt nur abwarten.
Denke nicht das Qundis sich dazu äussern wird - die haben das sicherlich auch alles irgendwo eingekauft und vermarkten das nur weiter.

edit:
Obwohl ich gerade gesehen habe, dass Qundis Softwareentwicker sucht - man scheint also doch einiges selbst zu machen.
Laut Inet: "Das System Q walk-by besteht aus Messgeräten, die zu einem voreingestellten Zeitpunkt die aktuellen Verbrauchsdaten, und zwar in einem schnellen Intervall, aussenden."


Martin

[kossmann]

Ich frag' Montag gerne mal nach, auch telefonisch.

[kossmann]

Ich habe mich heute erst mal mit meiner manuellen Dekodierung eines Paketes befasst und die CRC-Felder mit beachtet. Hier habe ich noch ein Verständnis-Problem, siehe Tabelle: In Byte 17 sagt mir ein DIF, dass ein Wert mit Datum/Uhrzeit folgt - als 32 Bit Integer. In Byte 27 sagt mir ein DIF, dass wieder ein Wert mit Datum/Uhrzeit folgt - nun allerdings als 24 Bit Integer. Ist das normal?

Hier mal die nicht interpretierbaren Values der Nachbarn - sieht identisch aus:

Code Auswählen Erweitern

WMBUS_LSE_228208_22_4 - 0c0008553000010613080bfffc02fd1700000c7878155559
WMBUS_LSE_228212_22_4 - 0c0008553000010613080bfffc02fd1700000c7800155559
WMBUS_LSE_228218_22_4 - 0c0008553000010613080bfffc02fd1700000c7806195559
WMBUS_LSE_228671_22_4 - 0c0008553000010613080bfffc02fd1700000c7880175559
WMBUS_LSE_228697_22_4 - 0c0008553000010613080bfffc02fd1700000c7898185559
WMBUS_LSE_58709293_65_7 - 0c0008553000010613080bfffc
WMBUS_LSE_58709356_65_7 - 0c0008553000010613080bfffc
WMBUS_LSE_58709397_65_7 - 0c0008553000010613080bfffc
WMBUS_LSE_58709398_65_7 - 0c0008553000010613080bfffc
WMBUS_LSE_58709399_65_7 - 0c0008553000010613080bfffc
WMBUS_LSE_58709400_65_7 - 0c0008553000010613080bfffc
WMBUS_LSE_58709402_65_7 - 0c0008553000010613080bfffc
WMBUS_LSE_58709403_65_7 - 0c0008553000010613080bfffc
WMBUS_LSE_58709404_65_7 - 0c0008553000010613080bfffc
WMBUS_LSE_58709405_65_7 - 0c0008553000010613080bfffc
WMBUS_LSE_58709438_65_7 - 0c0008553000010613080bfffc
WMBUS_LSE_58709439_65_7 - 0c0008553000010613080bfffc
WMBUS_LSE_58709440_65_7 - 0c0008553000010613080bfffc

[kossmann]

Ich habe eben mal mit Qundis telefoniert, denen ich ja schon am 6. August eine eMail geschrieben habe. Diese wurde dort vom technischen Support an´s Produktmanagement weitergeleitet. Der Verantwortliche ist dort momentan jedoch im Urlaub. Man hat meine Telefonnummer und wird mich hoffentlich zurück rufen.

Mir kam noch eine andere Idee: Kann es ggf. sein, dass die Zähler sowohl im S-, also auch (zu anderen Zeiten) im T-Modus senden? Mit dem CUL-433 hatte ich mein erstes Paket ja im S-Modus empfangen und lausche seit dem nur dort. Vielleicht senden die Zähler dort ja "irgendwas" und im T-Modus auswertbare Daten. Ich stelle für den Rest des Tages mal um...

[kaihs]

In Byte 27 sagt mir ein DIF, dass wieder ein Wert mit Datum/Uhrzeit folgt - nun allerdings als 24 Bit Integer. Ist das normal?

b10 = 0x04 bedeutet 16 Bit Integer, nicht 24 Bit.

Und in Byte 30 bedeutet das letzte Bit = 0, dass es sich um einen reinen Datumswert handelt, ohne Uhrzeit.

[kaihs]

Ich habe eben mal mit Qundis telefoniert, denen ich ja schon am 6. August eine eMail geschrieben habe. Diese wurde dort vom technischen Support an´s Produktmanagement weitergeleitet. Der Verantwortliche ist dort momentan jedoch im Urlaub. Man hat meine Telefonnummer und wird mich hoffentlich zurück rufen.

Dann ist die Hoffnung ja noch nicht ganz gestorben, dass wir evtl. doch noch Informationen bekommen.

Mir kam noch eine andere Idee: Kann es ggf. sein, dass die Zähler sowohl im S-, also auch (zu anderen Zeiten) im T-Modus senden? Mit dem CUL-433 hatte ich mein erstes Paket ja im S-Modus empfangen und lausche seit dem nur dort. Vielleicht senden die Zähler dort ja "irgendwas" und im T-Modus auswertbare Daten. Ich stelle für den Rest des Tages mal um...

Halte ich für unwahrscheinlich. S-Mode ist eigentlich der Standardmodus für Stationäre Zähler, aber Versuch macht klug.

[kossmann]

Augen auf nach Copy+Paste hätte die Fehlinterpretation vermieden, alles klar, Danke! Der Vollständigkeit halber hänge ich die nun hoffentlich korrekte Tabelle noch mal an.

Im T-Modus kam gestern und die ganze Nacht leider nicht, schade.

[kaihs]

Im Manufacturer Specific Teil steckt jetzt noch ein CRC, aber sonst haben wir die gleichen Ergebnisse.

Merkwürdig ist ja auch das Datumsfeld 'im Fehlerzustand' mit dem ungültigen Wert 0xffff.

Hast du mal am Gerät direkt geprüft, was da so eingestellt ist? Vielleicht ist da was falsch und sie senden deswegen nichts vernünftiges? Aber das ist auch nur eine sehr schwache Hoffnung.

[kossmann]

Wie kann ich denn das Gerät (die Wasseruhr) selbst prüfen?

Die Menge der Zähler und Quote (100%) der ManSpec-Werte spricht aber leider eine eigene Sprache. Solange Qundis sich nicht meldet, bzw. keine Infos liefert, habe ich momentan nur noch Hoffnung auf Januar, wo die Zähler ggf. andere Daten senden.

[mdewendt]

>Im Manufacturer Specific Teil steckt jetzt noch ein CRC, aber sonst haben wir die gleichen Ergebnisse.

wo genau steckt der CRC in dem Teil? Um Byte 39?  Oder meinst du am Ende Byte 51/52? Ich habe da einen Verdacht ...


Martin

[kaihs]

Wenn ich mich nicht verzählt habe in Byte 46/47.

Nach den 12 Byte für den Header kommen jeweils Pakete a 16 Bytes mit nachfolgenden 2 Byte CRC.

[kossmann]

Wobei man aber nicht weiß, ob dies im hersteller spezifischen Teil auch so ist, oder? Dort kann man ja vom Standard abweichen.

[kaihs]

Ich bin darauf hingewiesen worden, dass die Identification Number (Serial Number) immer 8 stellig mit führenden Nullen sein sollte.

Das ist in meinem Modul momentan nicht der Fall, wäre aber nur eine kleine, allerdings inkompatible, Änderung.
Zähler mit einer Identification Number mit weniger als 8 Stellen würden dann neu angelegt.

Führt das bei euch zu Problemen oder kann ich die Änderung durchführen?

Gruß,

Kai