UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[lvogt]

@ratte-rizzo
Der Timeout kommt nach 3 Sekunden. Du musst das Log chronologisch - also von unten nach oben - lesen.

Die Antwort, die der Stick in deinem 2. Logauszug schickt, kann ich zu nichts zuordnen.

Ich denke nicht, dass ich da ohne Hardware viel machen kann. Und soweit ich das den Einträgen hier entnehmen kann ist es jetzt auch nicht der Normalfall, dass man 8h lang den Adapter neu starten muss...

Edit: Ich kenne mich mit dem CUL ja wirklich nicht gut aus, aber hast du die Möglichkeit zu beeinflussen in welchem Mode und mit welchen Einstellungen der per default startet, wenn er neu bootet? Evtl. hilft es ja da direkt "bessere" Einstellungen zu setzen?

[ratte-rizzo]

Moin @lvogt

Dass ich das Log von unten her lesen muss, ist klar. Meine Idee war halt, den Timeout von 3s etwas zu vergrößern. Vielleicht 5s oder 10s. Solltest Du den Adapter bei Gelegenheit nochmal anfassen, kannst Du ja mal dran denken. Eilt ja nicht.

Immerhin steht jetzt fest, dass dieser (für mich) nervige Linux Kram mit Rechten, Durchreichen zu VM und so korrekt ist. Die Baustelle ist weiter eingekreist. Vielleicht hilfts ja anderen CUL Nutzern.

Letzte Frage: Was für eine Hardware nutzt / empfiehlst Du denn? Weihnachten kommt ja bald und die CUL HW und SW ist ja auch nicht gerade brandneu.

Dank & Gruß
Daniel

[lvogt]

@ratte-rizzo
Wie ich im Thread ab und zu schon mal erwähne, verwende ich den Adapter und sogar ioBroker einfach gar nicht selbst. Ich habe den Adapter ursprünglich im Rahmen meiner alten Arbeitsstelle geschrieben und ihn nach einer Weile "einfach so" weiter gepflegt.

Empfehlung zur Hardware kann ich daher kaum geben. "Damals" habe ich recht viel beim Testen den Amber Stick verwendet. Der hat ja zB auch diesen praktischen Mode der C und T gleichzeitig kann (hatte damit aber auch ab und zu Hardware(?) Problem). Der tatsächliche produktive Einsatz erfolgte dann mit der Embit Hardware, die aber - soweit ich weiß - nicht als USB Stick sondern nur direkt verbaut in irgendwelchem "Embedded Systemen" zu finden ist.

Der Amber Stick ist mittlerweile glaube ich aber gar nicht mehr so gut zu bekommen. Was recht gut zu bekommen ist, ist der IMST Stick von "alten" RWE SmartHome Angeboten auf eBay oä. Da muss man unter Linux noch ein bisschen was mit udev machen, damit der korrekte Treiber geladen wird (irgendwo hier im Thread zu finden), aber dann sollte es keine Probleme damit geben.

Der von dir gerade etwas in Zweifel gezogene CUL hat auch ein "inoffizielles" Update (auch schon nicht mehr ganz neu) das auch den C Mode bzw. eigentlichen einen C und T Mode implementiert verpasst bekommen. Wenn man also einen kombinierten Mode gebrauchen kann, ist das schon keine schlechte Wahl denke ich.

[gizmodlx]

@lvogt Ich erhalte regelmäßig die folgende Fehlermeldung vom wireless-mbus Adapter:

Ich dachte ja, der Wasserzähler würde sich beim ersten Ablesen irgendwie das richtige Datum ziehen, aber für 2 Parameter wird mir weiterhin der Wert "65535" (entspricht wohl 2128-03-31) ausgelesen. Wäre klasse, wenn man diese Meldung irgendwie unterdrücken könnte. Hast du da eine Idee?

[lvogt]

@gizmodlx

Die neueste "unstable" Version 0.8.5 sollte da jetzt keinen Fehler mehr ausspucken, sondern das nur noch als "INFO" loggen.

Das Problem ist, dass der Zähler da halt einen eigentlich ungültigen Wert zurückgibt - vermutlich weil das entsprechenden Datum nicht gesetzt ist.

[-cs-]

@lvogt

Hallo, habe es auf einem frischen Testsystem probiert, er schreibt immer noch die Error- Meldung.

wireless-mbus.0  2022-09-25 11:21:25.391	error	Unknown Kamstrup compact frame format

System ist heute neu auf einen Raspberry Pi aufgesetzt worden und Adapter ist v0.8.5

Edit:
Ups, da habe ich wohl zu viel quer durch die Beiträge gelesen, das ist ja eine andere Meldung oder?

Zähler ist Kamstrup Multical 21 mit IMST871A - Stick.

[lvogt]

@cs
Ja das ist offensichtlich eine völlige andere Fehlermeldung...

Du musst den Cache für Kompakt-Telegramme in den Einstellungen einschalten. Ich sollte das mal "automatisieren"...

[gizmodlx]

@lvogt said in Test Adapter wireless-mbus v0.8.x:

@gizmodlx

Die neueste "unstable" Version 0.8.5 sollte da jetzt keinen Fehler mehr ausspucken, sondern das nur noch als "INFO" loggen.

Das Problem ist, dass der Zähler da halt einen eigentlich ungültigen Wert zurückgibt - vermutlich weil das entsprechenden Datum nicht gesetzt ist.

Danke für das Update :+1:
Hab die Version 0.8.5 jetzt am Laufen. Der alte Fehler mit ungültigem Datum ist weg, dafür ist ein anderer Fehler neu dazu gekommen:

[fzzybllz]

Hallo zusammen,
da ich mittlerweile nicht mehr weiterkomme, bräuchte ich mal eure Hilfe.
Ich habe den Wireless M-Bus Adapter in v.0.8.2 zusammen mit einem nanoCUL (Arduino Nano + Ti CC1101) (der lag noch rum) am laufen.
Mittlerweile ist der Adapter auch endlich grün und wirft keine Fehler mehr. Geflashed wurde die Firmware von https://weetmuts.github.io/wmbusmeterswiki/nanoCUL.html
Der Adapter ist eingestellt auf Empfänger = CUL / Mode = T Mode / Die richtige Schnittstelle / Baudrate 38400. Nur in dem Setup wird der Adapter auch grün.
Lesen würde ich gerne einen "allmess Integral-V Ultra Lite".
Leider bekomme ich in den Objekten gar nichts ausgeworfen und im Protokoll auch gar nichts angezeigt. Mach ich hier was falsch oder passt noch was an der Hardware/Firmware nicht?
Vg

Edit: Der allmess Integral-V Ultra Lite ist zwar mein Wärmezähler, aber tatsächlich versuche ich mich eigentlich mit einem Itron EquaScan h MIU RF zu verbinden.

[lvogt]

@gizmodlx
Sorry, ich habe da am Wochenende nicht aufgepasst :see_no_evil: mit 0.8.6 sollte auch der Fehler nicht mehr passieren...

@fzzybllz
Der verlinkte Zähler behauptet im C2 Mode zu senden. Von daher solltest du wohl auch mal den "C/T" Mode des CULs ausprobieren. Ich sehe aber trotzdem zwei potentielle Probleme:
Das Datenblatt sagt C2 - evtl. bedeutet das, dass der Zähler nur antwortet wenn man erst ihm was sendet - da bin ich mir aber recht unsicher. Falls ja, dann ist dieser Adapter damit raus - senden ist bisher nicht drin.
Zum anderen steht im Datenblatt zwar brav wireless m-bus drin - aber nicht OMS - damit könnte es gut sein, dass die Daten nicht so einfach / gar nicht "lesbar" sind.

[fzzybllz]

@lvogt sagte in Test Adapter wireless-mbus v0.8.x:

@fzzybllz
Der verlinkte Zähler behauptet im C2 Mode zu senden. Von daher solltest du wohl auch mal den "C/T" Mode des CULs ausprobieren. Ich sehe aber trotzdem zwei potentielle Probleme:
Das Datenblatt sagt C2 - evtl. bedeutet das, dass der Zähler nur antwortet wenn man erst ihm was sendet - da bin ich mir aber recht unsicher. Falls ja, dann ist dieser Adapter damit raus - senden ist bisher nicht drin.
Zum anderen steht im Datenblatt zwar brav wireless m-bus drin - aber nicht OMS - damit könnte es gut sein, dass die Daten nicht so einfach / gar nicht "lesbar" sind.

@lvogt
Danke für die Antwort. Ja wer lesen kann, ist klar im Vorteil. Über den C2 Mode bin ich dann auch gestolpert, hab auf C/T-Mode umgestellt und siehe da. Alles funktioniert einwandfrei.
Mir wurden - wie erwartet - jede Menge Geräte (inkl. meiner 5 Zähler) aufgelistet.
Aktuell scheitert es "nur noch" an den AES Keys. Dazu hab ich gestern noch sehr sehr lange gesucht und bin aber nicht wirklich fündig geworden. Gibts da Tipps wie man die erhalten könnte?

[gizmodlx]

@lvogt said in Test Adapter wireless-mbus v0.8.x:

@gizmodlx
Sorry, ich habe da am Wochenende nicht aufgepasst :see_no_evil: mit 0.8.6 sollte auch der Fehler nicht mehr passieren...

Kein Problem :-) Version 0.8.6 wirft jetzt keinen Error mehr aus. Danke!

Der aus meiner Sicht letzte offene Punkt wäre noch die Anlage von bisher nicht vorhandenen Datenpunkten. Hier kommt es immer wieder zu Warnungen, weil der Adapter wohl neue (?) Datenpunkte nicht korrekt anlegt. Kann man zwar auch einfach ignorieren, aber lässt sich sicher auch eleganter lösen.

[Meldb]

Hallo kann ich mit diesem Adapter u. dem Cul 868 auch den Wasserzähler Kamstrup flowIQ 2200 Auslesen?

[olixAtiobroker]

Hallo, erstmal vielen lieben Dank für diesen Adapter!
Ich habe eine Diehl Sharky 775, den ich gerne mit dem CUL Stick auslesen würde. Prinzipiell scheinen der Stick und der Adapter die Daten auch zu empfangen, allerdings erhalte ich immer folgende Message:

Parser failed to parse telegram from device HYD-2788042f

Hat schon mal jemand den Sharky Wärmezähler erfolgreich eingebunden?
Bevor ich mich in wireless M-Bus und OMS einarbeite, wollte ich mal fragen ob jemand was mit der Message-Struktur unten anfangen kann und mir sagen, ob es eine gewisse Erfolgsaussicht zur Unterstützung gibt?
Ich kann gerne bei einer Umsetzung unterstützen.
Danke und Grüße,
Oliver
Hier das komplette Log:

2022-10-03 22:18:58.201 - info: wireless-mbus.0 (27585) starting. Version 0.8.5 in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v14.18.1, js-controller: 4.0.19
2022-10-03 22:18:58.312 - debug: wireless-mbus.0 (27585) Created device of type: CUL
2022-10-03 22:18:58.321 - debug: wireless-mbus.0 (27585) CUL: TX: 560d0a
2022-10-03 22:18:58.338 - debug: wireless-mbus.0 (27585) CUL: RX: 000a
2022-10-03 22:18:58.389 - debug: wireless-mbus.0 (27585) connected set to false
2022-10-03 22:19:01.338 - info: wireless-mbus.0 (27585) CUL: Error getting CUL version: Timeout waiting for response
2022-10-03 22:19:01.339 - debug: wireless-mbus.0 (27585) CUL: TX: 5832310d0a6272630d0a
2022-10-03 22:19:01.360 - debug: wireless-mbus.0 (27585) CUL: RX: 434d4f44450d0a
2022-10-03 22:19:01.361 - info: wireless-mbus.0 (27585) CUL: Receiver set to C-MODE and data reporting with RSSI
2022-10-03 22:19:01.422 - debug: wireless-mbus.0 (27585) connected set to true
2022-10-03 22:19:13.355 - debug: wireless-mbus.0 (27585) CUL: RX: 6237333434323432333246303438383237383134314543333437413845303036353730324436353933313941414436383745353241464532373737
2022-10-03 22:19:13.386 - debug: wireless-mbus.0 (27585) CUL: RX: 3143393138384433333831344242304630454532324143413536304335334445353132344639433233463843324338303238414646354442383345313637433441443939314331414234324132414332443939414430323337464138323937423941424339444238413944303041313244304142463339
2022-10-03 22:19:13.417 - debug: wireless-mbus.0 (27585) CUL: RX: 323731313237343641384236413839443531433641323446393543314131333236453930323133454242433835453531374545423738464441394237383339333932374337344237313830354146454331363345364142383133390d0a
2022-10-03 22:19:13.419 - debug: wireless-mbus.0 (27585) CUL: Message received: 734424232f0488278141ec347a8e0065702d659319aad687e52afe27771c9188d33814bb0f0ee22aca560c53de5124f9c23f8c2c8028aff5db83e167c4ad991c1ab42a2ac2d99ad0237fa8297b9abc9db8a9d00a12d0abf3927112746a8b6a89d51c6a24f95c1a1326e90213ebbc85e517eeb78fda9b78393927c74b71805afec163e6ab8139
2022-10-03 22:19:13.422 - debug: wireless-mbus.0 (27585) 734424232f0488278141ec347a8e0065702d659319aad687e52afe27771c9188d33814bb0f0ee22aca560c53de5124f9c23f8c2c8028aff5db83e167c4ad991c1ab42a2ac2d99ad0237fa8297b9abc9db8a9d00a12d0abf3927112746a8b6a89d51c6a24f95c1a1326e90213ebbc85e517eeb78fda9b78393927c74b71805afec163e6ab81
2022-10-03 22:19:13.426 - debug: wireless-mbus.0 (27585) Short header
2022-10-03 22:19:13.427 - error: wireless-mbus.0 (27585) Warning unknown security mode: 16
2022-10-03 22:19:13.428 - error: wireless-mbus.0 (27585) Encryption mode 10 not implemented
2022-10-03 22:19:13.431 - debug: wireless-mbus.0 (27585) Parser failed to parse telegram from device HYD-2788042f
2022-10-03 22:19:46.124 - debug: wireless-mbus.0 (27585) CUL: RX: 62373334343234323332463034383832373831343145433334374139303030363535
2022-10-03 22:19:46.156 - debug: wireless-mbus.0 (27585) CUL: RX: 443244374530354346384243424633354435314345433431464242383144443235454139424646423433443432343333373034383842374536413243463741373342323641323334414139384337413242454142393739464331443638373843344544423136424538354538453530353343364330333941364434
2022-10-03 22:19:46.187 - debug: wireless-mbus.0 (27585) CUL: RX: 364541423334333938384239304443314233344233393430464632463934363231423130364135354135304537453945414338363744313632364445333137353435414630433030383244394436393735334631353846423638383736393938373834423330344243303541383033410d0a
2022-10-03 22:19:46.188 - debug: wireless-mbus.0 (27585) CUL: Message received: 734424232f0488278141ec347a9000655d2d7e05cf8bcbf35d51cec41fbb81dd25ea9bffb43d4243370488b7e6a2cf7a73b26a234aa98c7a2beab979fc1d6878c4edb16be85e8e5053c6c039a6d46eab343988b90dc1b34b3940ff2f94621b106a55a50e7e9eac867d1626de317545af0c0082d9d69753f158fb68876998784b304bc05a803a
2022-10-03 22:19:46.189 - debug: wireless-mbus.0 (27585) 734424232f0488278141ec347a9000655d2d7e05cf8bcbf35d51cec41fbb81dd25ea9bffb43d4243370488b7e6a2cf7a73b26a234aa98c7a2beab979fc1d6878c4edb16be85e8e5053c6c039a6d46eab343988b90dc1b34b3940ff2f94621b106a55a50e7e9eac867d1626de317545af0c0082d9d69753f158fb68876998784b304bc05a80
2022-10-03 22:19:46.190 - debug: wireless-mbus.0 (27585) Short header
2022-10-03 22:19:46.190 - error: wireless-mbus.0 (27585) Warning unknown security mode: 29
2022-10-03 22:19:46.190 - error: wireless-mbus.0 (27585) Encryption mode 1d not implemented
2022-10-03 22:19:46.191 - debug: wireless-mbus.0 (27585) Parser failed to parse telegram from device HYD-2788042f
2022-10-03 22:20:02.644 - debug: wireless-mbus.0 (27585) CUL: RX: 6237333434323432333246303438383237383134314543333437
2022-10-03 22:20:02.661 - debug: wireless-mbus.0 (27585) CUL: RX: 41393130303635353432443746373733423131373945453630434337463534383332334141453939453837463144333130313536373133454145353245
2022-10-03 22:20:02.692 - debug: wireless-mbus.0 (27585) CUL: RX: 424530323030353732344644433145354636393541353541334141334546334534424344343635333537383533383235343733454342393633414644414531304634463830374346303336443037373439323641424643444546333635424443413838353642353330343744324345334542434435353038
2022-10-03 22:20:02.722 - debug: wireless-mbus.0 (27585) CUL: RX: 31324339333430463242444344353941353636423130313939324230354230383735334244413534433141343030423738394544303436383732383133410d0a
2022-10-03 22:20:02.723 - debug: wireless-mbus.0 (27585) CUL: Message received: 734424232f0488278141ec347a910065542d7f773b1179ee60cc7f548323aae99e87f1d310156713eae52ebe02005724fdc1e5f695a55a3aa3ef3e4bcd465357853825473ecb963afdae10f4f807cf036d0774926abfcdef365bdca8856b53047d2ce3ebcd550812c9340f2bdcd59a566b101992b05b08753bda54c1a400b789ed046872813a
2022-10-03 22:20:02.724 - debug: wireless-mbus.0 (27585) 734424232f0488278141ec347a910065542d7f773b1179ee60cc7f548323aae99e87f1d310156713eae52ebe02005724fdc1e5f695a55a3aa3ef3e4bcd465357853825473ecb963afdae10f4f807cf036d0774926abfcdef365bdca8856b53047d2ce3ebcd550812c9340f2bdcd59a566b101992b05b08753bda54c1a400b789ed04687281
2022-10-03 22:20:02.725 - debug: wireless-mbus.0 (27585) Short header
2022-10-03 22:20:02.725 - error: wireless-mbus.0 (27585) Warning unknown security mode: 20
2022-10-03 22:20:02.725 - error: wireless-mbus.0 (27585) Encryption mode 14 not implemented
2022-10-03 22:20:02.726 - debug: wireless-mbus.0 (27585) Parser failed to parse telegram from device HYD-2788042f

[lvogt]

@gizmodlx Ja wenn der Adapter zum selben Gerät unterschiedliche Telegramm bekommt / bekommen hat (bei dir evtl. aufgrund des Bugs den ich in 0.8.5 eingebaut hatte), dann wird das nicht besonders gut gehandhabt. Du wirst du Meldung los, wenn du einmal das Gerät im Objektbaum löschst - zumindest wenn du dir das leisten kannst (in Bezug auf gelöschte History oder was vl. sonst von den Datenpunkten abhängt)

@Meldb Vermutlich dürfte das gehen - aber natürlich alles ohne Garantie ;)
Du brauchst natürlich in jedem Fall den AES Key falls verschlüsselt gesendet wird (was bei dem Gerät der Fall sein dürfte). Der Key kann nur vom Hersteller / Wasserversorger erhalten werden @fzzybllz !

@olixAtiobroker Ich bin etwas über die Ausgaben irritiert. Der Anfang eines der Telegramme den ich mir jetzt angeschaut habe wirkt sehr "spezifikations unkonform". Es fängt schon mit der Zähler ID an: HYD-2788042f <- das f hinten passt schon nicht so richtig. Kannst du irgendwo am Zähler eine ähnliche Nummer finden?
Dann kommt ja die Meldung zum security mode. Zum einem ist es schon merkwürdig dass der security mode ja scheinbar von einem zum nächsten Telegramm sich ändert, zum anderen sind diese Modes (zumindest nach OMS) nicht spezifiziert.
Was aber irgendwie gegen korrupte Daten spricht, ist dass die CRC Prüfsummen alle passen... Ich bin etwas ratlos... :shrug:

[olixAtiobroker]

Hallo @lvogt,
erstmal vielen Dank für die Antwort. Der Diehl Sharky 775 ist ein "Hydrometer" und meiner hat die Seriennummer 4181-2788 - von daher passt der erste Teil der ID "HYD-2788", die "8042f" die danach kommt, hat keine Entsprechung.

Laut Datenblatt unterstützt der Zähler "Open Metering Standard ... Generation 3 Profil A oder Generation 4 Profil B" - wobei ich mich da noch nicht schlau gemacht habe.

Kannst Du mir einen "Link" auf die Spezifikation schicken (oder ggf. sagen, welche Spec. Du erwartest) bzw. was das Log-Telegramm zeigt? MBUS oder nur OMS (oder was anderes)? Ich würde dann ggf. weiter in den Specs. suchen, mir fehlt aber der Einstiegspunkt und eine Idee was das Log wirklich zeigt.

Besten Dank und Grüße,
Oliver

[olixAtiobroker]

@lvogt, ach ja und unterstützt Deine Implementierung "Generation 3 Profil A/ Generation 4 Profil B"?
Nochmal Danke,
Oliver

[Meldb]

@lvogt Hallo danke für die Antwort. Denn AES Key habe ich den Stick muss ich mir erst besorgen.

[lvogt]

@olixatiobroker
Die Zeile mit Message received ist das vollständige Telegram als Hexstring. Die OMS Spezifikation gibt's hier: https://oms-group.org/open-metering-system/oms-spezifikation
Zum Großteil (der - bisher - relevante Teil) wird das vom Adapter auch unterstützt. Ich bleibe aber dabei dass irgendwas grundsätzlich schief läuft da das "f" in der Zähler ID eigentlich schon dem absoluten "Minimum" als MBUS bzw. EN 13757-2 widerspricht.

[Wolfi]

Habe einen nanoCUL mit Firmware M-Bus (Version nanoCul_r568_mbus_c1t1_bufsize300) gekauft.
Verbindung mit dem Adapter ist "grün" aber bekommen keine Daten im Debug.

Gibt es einen Unterschied der M-Bus Firmware ob für FHEM oder iobroker?

Oder was habe ich für ein Probehm?