amsreader-firmware
amsreader-firmware copied to clipboard
UtilitechAS
Feature request: Pass missing values from kamstrup dataframe to mqtt
Hi
First of all, thank you for creating this!
Would it be possible to pass the rest of the values from the kamstrup dataframe on to mqtt, it looks like they are already defined here: https://github.com/gskjold/AmsToMqttBridge/blob/master/frames/Kamstup-Encrypted.raw
Thanks in advance
I have considered this before and the best solution I can think of is to expose all "unknown" OBIS values as raw values to separate topics. F.ex. using the raw file you referred to: {publish topic}/1/1/1/8/0/255 = 1152202 {publish topic}/1/1/2/8/0/255 = 0 and so on...
If you have any other suggestions, please let me know.
No I was actually thinking something along those lines, as that would also make it easy to support new meters that have different values.
If done in that format, I think they should only be published if format is Raw (Full)
May I suggest to use human readable topics instead? e.g. "L1_Current_Instantaneous". This makes it much easier to decipher the topics. Also using / as deviders, is confusing from a MQTT structure perspective.
May I suggest to use human readable topics instead? e.g. "L1_Current_Instantaneous". This makes it much easier to decipher the topics.
That would mean maintaining a mapping of all possible OBIS codes to names, which just means unnecessary support for me when someone starts using this software in a new country. But I understand the request and will consider it.
Also using / as deviders, is confusing from a MQTT structure perspective
Not at all, this applies perfectly to the purpose of MQ subtopics.
May I suggest to use human readable topics instead? e.g. "L1_Current_Instantaneous". This makes it much easier to decipher the topics.
That would mean maintaining a mapping of all possible OBIS codes to names, which just means unnecessary support for me when someone starts using this software in a new country. But I understand the request and will consider it.
I don't get that. OBIS codes does not change, as they are defined in the IEC standard. Language-wise English should be sufficient.
Also using / as deviders, is confusing from a MQTT structure perspective
Not at all, this applies perfectly to the purpose of MQ subtopics.
If the idea is to build a large tree-structure, then I think I need a visualization to understand it. Why not e.g. "/ams2mqtt/1.1.1.8.0.255", with payload xxx, if readable names isn't an option? From what I read, you aim to build e.g. "/ams2mqtt//1/1/1/8/0/255" which, in total, will break into a rather large tree structure, some with very few branches.
OBIS codes does not change meaning, no. I could implement a name map for all possible electricity OBIS codes. Seeing that the firmware is already at 94% used flash space for the ESP32 partition table I use, first impression is that this is a bit of wasted space for something that very few people care about. But I would need a full list to make the final decision. As for the actual names an official name list is highly preferred, as I have seen a few contradicting naming schemes for OBIS codes in the past.
I understand now what you mean structure wise. I guess you (and many others) use graphical visualizers to look at message stream. Personally I have never done that as I do not consider the topic to be a tree, but rather a routing key in a delivery system. Anyway, you have a fair point here regarding the tree structure it would create. I will dive further into IEC62056 to determine the best solution.
As for using dot in topic name, this is no problem for MQTT, but I suspect for anyone using ActiveMQ or RabbitMQ as brokers there could be issues doing so. If I remember correctly, both use dot as topic separator. Not 100% sure what a dot int the topic name would cause in these cases. Investigation needed.
Just to clarify: I am not against the idea, but seeing that this firmware have recently caught some traction in the community, I try to avoid things I suspect could generate future support. If you believe I am wrong about that, bring facts (documentation, lists etc) to the table to convince me.
@gskjold I've created a draft PR (#322) for extracting per phase usage and exporting as requested in #317. Would you mind taking a look before I proceed?
The idea with this issue was to extract and send any (known or unknown) OBIS to MQTT without wasting any more memory. Storing the data in AmsData class like you do in your PR was not my intention in this case, but I will consider it. The data you have based the implementation on is only available from Danish Kamstrup meters (as far as I know) and have very little value for other users. My concern is that we are adding complexity and memory footprint for a very small group of users. I am not trying to be negative here, but I have to consider complexity vs usefulness with any new features.
That being said, your solution is clean and follows the current methodology, so I will consider merging it, but I have to determine if it is compatible with a v2.2 branch I am working on. If I decide to use your PR, I would ask you to separate all the data from the ha3.json and add a ha4.json to contain this data instead, simply because there are no need for all the meters to send a json with lots of empty fields if it isn't necessary.
Thank you for the constructive feedback. I appreciate that these values only exist for Danish Kamstrup meters but I do consider them very useful anyway. This is my first time working on the Arduino platform so I'm not too well acquainted with the boundaries and restrictions.
I can't say whether AmsData is the right place for those values. I simply don't have enough knowledge or experience with this code base but if you have a different model in mind I'll be happy to take a stab at it.
I agree the values should be moved from ha3.json to a new ha4.json. The reason I put them in ha3.json was that it already had the PF values which I believe is also only reported for Danish Kamstrup meters.
Should I just update this PR with the ha4.json work for now? Ans should the PF values be moved from the current ha3.json to a new ha4.json, or just leave ha3 as-is?
Agree, move PF values as well to ha4.json. Update your PR with this change and I will conduct some tests during my next work session.
I think that between the latest change here with import/export for each phase, this is pretty much solved. There isn't many meters out there that report much more than we got implemented now, and the amount of users interested in the rest is low. For those who are interested in anything that isn't extracted, please use MQTT HEX dump option