[FR] expose sensor info via OctoPrint eventmanager.

[StefanCohen]

Hi!

I'm developing the Dashboard plugin and I recently received a feature request to support dht11 temperature sensors. Rather than implementing this myself, I'm looking to see if you would be interested in exposing the sensor info you have to other plugins?

I haven't investigated your viewModel or API yet. I have a feeling that it is probably possible to get the info via those mechanisms but I see two problems with that:

1. The viewModel approach makes the solution fragile and vulnerable to UI changes on your end.
2. The API requires user configuration.

I propose that you implement support for custom events via the OctoPrint eventManager.

This could be an event that is fired on a fixed time interval (every two seconds?) or whenever there is a change in any of the sensor values.

I'm primarily interested in temperature sensors but there may be others that are interesting to expose to other plugins too.

Is this something you would be interested in?

[UnchartedBull]

Funny thing, I just thought about the same thing for OctoDash. We're basically developing a similar thing (his is for the Website, mine for the Display) and we are running into the same problems.

I've tried reading the temperature sensor via a electron app which is not really that reliable and limits the electron builds to armv7l architecture basically. I did some research and found out, that you can retrieve the temperature via the settings API. It doesn't seem to update though and is kind of hacky and carries lot of unnecessary data.

I'll open a pull request where I tried to add a GET API for the temperature sensors and tried sticking to your existing code style. I don't want to open another issue for this, but exposing the data via an API will be great and there is demand for that. I'll link the PR once I've confirmed that it is working.

[vitormhenrique]

There is already an API and it is possible to get all data from current methods, the author of the telegram plugin uses it. I’m now on vacations and not able to work on this plugin for a while. I’ll take a look when I get back. Vitor Henrique

[UnchartedBull]

You mean the OctoPrint-telegram Plugin? Because I can't find any use of the Enclosure Plugin there. I've also had a look at your code and it seems like you can retrieve most of the stuff except the rpi_inputs array, which is the one I'm interested in. If there is a way to retrieve the inputs please kindly point me in the right direction.

Enjoy you vacation!

[StefanCohen]

Thanks for the feedback!
I would just like to know if you would be open for a PR if I and @UnchartedBull work together to improve how the data is exposed thru both the existing API and thru the event manager?

We are both interested in the same information but we have slightly different use cases. My Dashboard plugin will always run on the same OctoPrint Instance as the Enclosure plugin and therefore share the event bus. It would therefore reduce the configuration effort for users and also reduce the complexity to use the built-in messaging feature so that's the reason for me pursuing that path rather than the rest api. OctoDash will mostly (always?) run on another host so it makes sense to use the rest api in that case.

Best regards,
Stefan

[vitormhenrique]

PR’s are always welcome, there is one issue already open, for a proper RESTfull API, I would like to change current implementation to follow it. But I haven’t had to much time to work on the plugin lately.

[vitormhenrique]

Follow issue #169

[UnchartedBull]

Ok I think we can take on this challenge then. @StefanCohen and I will work on the same fork to do a proper REST API and the custom events thing. it may take a few days but it hopefully helps more people after that!

And yeah OctoDash always runs on a separate instance, because it is javascript based and doesn't have direct access to the Python OctoPrint instance.

[vitormhenrique]

Awesome, just one thing, let’s not remove the current api, as I know that some other users are using it on custom integrations. First release let’s keep both api’s and deprecate the old one on a future release. Thanks! Vitor Henrique