Rest interface for miflora

[jeroenterheerdt]

I created a simple REST interface for miflora.

[coveralls]

Coverage remained the same at 92.727% when pulling 2bb3fe6 on jeroenterheerdt:master into 66c6202 on open-homeautomation:master.

[coveralls]

Coverage remained the same at 92.727% when pulling 2bb3fe6 on jeroenterheerdt:master into 66c6202 on open-homeautomation:master.

[coveralls]

Coverage remained the same at 92.727% when pulling 2bb3fe6 on jeroenterheerdt:master into 66c6202 on open-homeautomation:master.

[coveralls]

Coverage remained the same at 92.727% when pulling 2bb3fe6 on jeroenterheerdt:master into 66c6202 on open-homeautomation:master.

[coveralls]

Coverage remained the same at 92.727% when pulling 2bb3fe6 on jeroenterheerdt:master into 66c6202 on open-homeautomation:master.

[ChristianKuehnel]

@jeroenterheerdt thanks for the contribution.

Some questions:

• Does it make sense to add all of that to the miflora library? Right now the focus is to offer a library, not an appliation. Would it make sense to provide a separate application as a separate instead (see https://github.com/open-homeautomation/miflora#projects-depending-on-miflora)?
• What is the use case? Run miflora as deamon and allow others to poll data from it?
• Shouldn't we put the MAC on the URL as well? Something like /api/v1.0/11:22:33:44:55:66/moisture?
• If I understand the life cycle correctly, you instantiate a new poller object with every call. So that means with every call you directly talk to the sensor, right? Would it make sense to add some sort of caching?

[jeroenterheerdt]

Great questions. I whipped this up quickly because (use case) : the reach of Bluetooth in my situation is not enough, so I build this rest api to run on a gateway. The gateway talks to the sensor and my consumer uses the rest api. It works fine this way. I was not planning to introduce caching etc. Thought the least I could do is share the code back to maybe serve as an extra demo or sample.

[ChristianKuehnel]

Are you aware of the existing solutions for this problem using MQTT (instead of REST)?

• https://github.com/ChristianKuehnel/plantgateway
• https://github.com/ThomDietrich/miflora-mqtt-daemon

[jeroenterheerdt]

Well yes, but why stand up MQTT on a limited chip when you can have a simple rest interface? Regardless, include the code or not. I do not mind, it serves my purpose. If you do not want it, fine by me.

[ThomDietrich]

I'm against the addition of such a feature here. "miflora" is a library for a pretty obvious reason - to decouple the hardware access from the use case specific integration.

To that end I've for example developed the MQTT daemon but a REST API based on the library is also a great idea! Your question if REST is better then MQTT can't be answered... Which is more useful solely depends on your use case, don't you agree?
May I suggest to push the specific code to it's own repository depending on miflora, then adding it to the list here: https://github.com/open-homeautomation/miflora#projects-depending-on-miflora
?

If you want to profit from my already existing systemd service unit implementation you are also invited to add your functionality in https://github.com/ThomDietrich/miflora-mqtt-daemon as a PR ;)

[ChristianKuehnel]

I agree with @ThomDietrich
Services on top if the library should be implemented in another project.