Kamstrup MC401 Protocol

Agents, Protocols and APIs
1

Hi Guys,

I like to share with you my protocol code for ORv3 dedicated to read out Multical(R) 401 Heater Meter from Kamstrup. You can find it at Github: GitHub - siliconehuntsman/mc401: MC401 Protocol for Open Remote v3
It is fully functional code, though it requires hardware part either from Kamstrup or DIY to communicate with the meter. I will document the simple circuit soon. The code has been tested outside of OR server with limited “manual” in-server tests.

This is my first real Java code and effect of OpenRemote server exploration. I’m open for any suggestions how to improve this code.

Best regards,
Michal

2

Hi Michal, nice to see you back :slight_smile: Note there will still be some asset refactoring, so your protocol might need some adjustments. Will keep you posted.

3

Hi Pierre, please just keep me up-to-date with mods. There is a good side of isolation that I have more time for nice things :slight_smile:

1 Like
4

Hi Michal, this is a good time to try again (for multiple reasons: isolation combined with the newest version) :slight_smile:

5

Thanks for message, I will check.

6

Hi Pierre,
I see that you have done a pretty major change. Would you have some summary of these mods? Let’s say a transition path - this replaced by that and so on. I see missing AssetAttribute, MetaItemDescriptor and ProtocolExecutorService to call just a few from the top of my error list.
This would help me to reduce time of understanding the new model and updating code of MC401 protocol and yet another one that I’m working on.

Best regards,
Michal

7

Hi,

As you’ve discovered there was a big refactor of our model and protocol SPI and as we haven’t made an official release yet there isn’t much in terms of notes for dealing with the changes.

Worth looking at the changes needed in for example KNXProtocol.java to work with the new changes as this will give you a good guide of what to do to update any protocol:

agent/src/main/java/org/openremote/agent/protocol/knx/KNXProtocol.java

Here’s some helpful info:

  • AssetAttribute → Attribute
  • Protocols are no longer singletons but one instance per Agent; you’ll see that each Protocol has a corresponding Agent class see here for example.
  • Each Asset type now has a concrete class and Agents are a sub type of Asset so they therefore have their own classes also (this gives us better type safety)
  • An Agent's configuration is now stored in individual attributes rather then all stuffed into a ProtocolConfiguration attribute; these attributes are defined in the Agent class.
  • agentLink MetaItem now contains all the configuration needed to connect an attribute to a specific Agent

Hope this helps.

Rich

1 Like
8

Hi Rich,

Thanks for this summary, it helped me to start migration. I have built a skeleton of new Agent and Protocol. I see them in Manager.
Let me suggest to add information at Wiki about use of ServiceLoader mechanism, need for adding own class implementing AssetModelProvider interface and a manifest pointing to this class.

By the way, other point connected with Agents. Do you plan to change how attribute agent link is defined in this new version? The Text Field with JSON is rather cumbersome to use. If not then maybe a template of values can be automatically inserted there.

Thanks,
Michal

1 Like