Gandalf/OctoPrint-Enclosure
1
0
Fork 0
Code Issues 156 Pull Requests 6 Actions Packages Projects Releases 28 Wiki Activity

[FR] expose sensor info via OctoPrint eventmanager. #260

New Issue
Open
opened 2019-10-02 06:41:43 +01:00 by StefanCohen · 8 comments
StefanCohen commented 2019-10-02 06:41:43 +01:00 (Migrated from github.com)
Copy Link

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?

Hi! I'm developing the [Dashboard](https://github.com/StefanCohen/OctoPrint-Dashboard) plugin and I recently received a [feature request](https://github.com/StefanCohen/OctoPrint-Dashboard/issues/57) 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](https://docs.octoprint.org/en/master/plugins/hooks.html#sec-plugins-hook-events-register-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?
👍 2
UnchartedBull commented 2019-10-08 22:48:09 +01:00 (Migrated from github.com)
Copy Link

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.

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.
👍 1
vitormhenrique commented 2019-10-09 08:00:09 +01:00 (Migrated from github.com)
Copy Link

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

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 commented 2019-10-09 09:38:31 +01:00 (Migrated from github.com)
Copy Link

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!

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 commented 2019-10-09 10:14:41 +01:00 (Migrated from github.com)
Copy Link

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

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 commented 2019-10-09 11:57:13 +01:00 (Migrated from github.com)
Copy Link

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.

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 commented 2019-10-09 12:00:32 +01:00 (Migrated from github.com)
Copy Link

Follow issue
https://github.com/vitormhenrique/OctoPrint-Enclosure/issues/169

Follow issue https://github.com/vitormhenrique/OctoPrint-Enclosure/issues/169
UnchartedBull commented 2019-10-09 12:18:49 +01:00 (Migrated from github.com)
Copy Link

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.

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 commented 2019-10-09 13:00:30 +01:00 (Migrated from github.com)
Copy Link

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

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
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
documentation
duplicate
enhancement
help wanted
invalid
Missing Data
Missing necessary data to troubleshoot
 question
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Gandalf
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Gandalf/OctoPrint-Enclosure#260
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?