You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Where to start: The "application" data of wireless and wired M-Bus messages follows basically the original M-Bus specification. OMS is more or less a subset of the whole M-Bus specification by limiting the specification, mostly at link layer level.
The wmbus_decoder class in this repository is in my (biased 😉) opinion one of the best (open source) parsers for M-Bus (application) data*. Of course, the parser usually expects (link layer) data as defined for wireless M-Bus, but it has already some limited support to parse "wired" M-Bus data. OBIS data is sometimes (always?) SML formatted, which is not supported!
What is also missing completely is anything connected with "sending" messages, as the common use case for wmbus receivers is only to listen for incoming messages.
*At least in terms of results - the code could be organised better...
In this case the Format is not obis or sml - in fact each Oms energymeter provides a list to map the mbus „data order“ to the corresponding obis values ;-)
Also sending is not an issue because read only is fine.
I would have some fetched data and also the key that I could provide. Alternative would be to have the library as own npm package to use then in Indic my libs/adapters or such?!
What do you think? If easier we also could sync via telegram or WhatsApp.
... see Apollon77/smartmeter-obis#4 (comment) ... as I understand in fact wmbus and OMS is kind of very near to each other or?!
The text was updated successfully, but these errors were encountered: