FEMS: Added support for the FEMS API

[DerStoecki]

With this Plugin it is possible to connect to the FEMS via REST. (Easy to add additional datapoints if some additional data is needed etc)

NOTE: Tested with OpenEMS-Edge not a FEMS system (but its core is openems-edge so logic would be the same)

nymea-plugins pull request checklist:

• [✓] Make sure the pull request's title is of format "Plugin name: Add support for xyz" or "New plugin: Plugin name"

• [✓] Did you test the changes on hardware, if not (e.g. absence of required hardware), please mention a person to confirm it has been tested.

• [✓] Did you update the plugin's README.md accordingly?

• [✓] Did you update translations (cd builddir && make lupdate)?

[CLAassistant]

All committers have signed the CLA.

[mzanetti]

Thanks for the contribution. Please accept the CLA to allow us to actually use this.

[mzanetti]

Thanks for signing the CLA.

So, to begin with, in order to allow integrating this plugin into the nymea-plugins reporistory, the debian packaging structure for the standalone packaging would need to be removed and instead hooked into the main plugin dpkg. For that, please just remove the entire fems/debian folder and add just the package into the main repositories debian/control file, as well as providing the according debian/nymea-plugins-fenecon.install.in.

Generally we name the packages according to the vendor name, so in this case it would probably be nymea-plugin-fenecon instead of nymea-plugin-fems. That would allow extending the plugin also for other devices by fenecon, as well as ease up searching for the user as I think a user would rather search for fenecon instead of fems.

[mzanetti]

I've also looked into this device recently and it seems that it would also support modbus TCP. Now I'm totally fine with using the REST API instead of Modbus but just out of curiosity, what was your rationale for choosing the REST api over modbus?

[DerStoecki]

I've also looked into this device recently and it seems that it would also support modbus TCP. Now I'm totally fine with using the REST API instead of Modbus but just out of curiosity, what was your rationale for choosing the REST api over modbus?

Hi sorry for the delayed answer, I've been to the OpenEMS Hackathon and I'll answer with the github app. Thanks for the suggestions, I'll edit the packages next week on monday/Tuesday depends on my schedule. The reason for the usage of the rest api instead of the Modbus api has 2-3 reasons. The logic of the openems edge /fems are so called channeladresses. Those addresses are a concatenation of the configured openems device id and 'channel' ID. Those will remain the same /are more easy to grasp than the Modbus api. Next reason is The Modbus channel may change from fems to fems depending on the configuration of the fems therefore its pretty hard to say 1 Modbus address might stay the same and means the same thing. But tbh I don't know much about the fems product itself and more about the openems stack. And last but not least by using the rest api you can easily connect to an openems edge instead of a fems (compatible to both) or can set up your own openems and connect to nymea via the rest api(as long as your are using device id's such as meter0, ess0 and so on) And if you want to expand the code and connect to... Let's say an evcs... You can have a look into the openems repo - > see the channels - >implement those very quick into nymea. As long as the ID stays the same (usually evcs0, meter0, ess0) you can always be assured to get the correct data. By using the Modbus api (if you have a look into the openems repo - > controller.modbus.api) you can see that it depends on the order of components what Modbus address certain data points will be assigned to.

(to be fair the 'sum' data points will stay at the same address)

However, REST with openems is way more powerful since you can read any 'channel' data point from an openems component.