Rest interface for miflora

jeroenterheerdt commented 6 years ago

I created a simple REST interface for miflora.

coveralls commented 6 years ago

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

coveralls commented 6 years ago

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

coveralls commented 6 years ago

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

coveralls commented 6 years ago

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

coveralls commented 6 years ago

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

ChristianKuehnel commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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

jeroenterheerdt commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

basnijholt / miflora

Rest interface for miflora #86