Hub as a device

📢 Feedback Feature Requests
1

please provide a driver for the hubitat hub that make the hub available as a device. commands like reboot() should be available thru this driver along with attributes like:

  • appsTotal
  • appsRunning
  • cpuUtilization
  • memoryUsed
  • memoryFree
  • appDetails [id=id, name=name, cpuUsage=cpu, memoryUsage=memory, ...]

thank you.

2 Likes
2

Not seeing a use case for this.

3

Support has access to this info, I suspect. Yet, it would be helpful, during development, to see "what did I just do?" in relation to an app or driver just added. Before and after, in a sense.

My "vote" is for access to some means to detect "something is misbehaving" - without regard as to how that info is shared.. driver, extended status URL, etc. I already know that /reboot does that, could there be a /diagdata ?

2 Likes
4

"I suspect". No, not without inordinately digging into things, which we ordinarily would not do. It sounds like you are talking about how to debug your code. These sort of diagnostics aren't the means to do that, and generally won't help that.

5

I guess it's more a "do I need to debug my code?" issue. I'd like a clue about "Do I have a memory leak?" or any of the hundred other instability potentials. With the data one can gather a baseline and then run some tests and get trend data.

1 Like
6

Memory leak? Hundred other instability potentials? Seriously? In sandboxed Groovy? You are thinking of some other sort of development environment than this one.

I'd suggest you need to debug your code when it doesn't work. You don't need to diagnose the platform to debug your code.

7

I vote for a way to reboot the hub from the cloud...I still experience missed events every now and then, and going on a trip now I wish I could reboot the hub if need be...

1 Like
8

here are a few i had in mind ... @csteele has already mentioned some of the same:

  1. hub crawling ... reboot hub.
  2. hub misbehaving check stats.
  3. driver misbehaving check stat.
  4. app misbehaving check stats.
  5. hub is a device thats hosts child devices and apps ... treat like a device and expose device details.
  6. cooler than the other guys. :wink:

its not about debugging the platform. its about debugging the effects of a driver or app on the platform. this information would be an enormous help for many developers who are writing code to run on this platform.

thank you.

9

I feel the same so i have done 2 things.

  1. I have an RPi on the my network so I can VNC into it and from the RPi connect to my HE to reboot/amend pistons etc. etc. should I wish to.

2, My hub is plugged into a WeMo plug that is not discovered by my HE hub. I can use the WeMo app to remotely turn my WeMo outlet on and off and therefore turn my hub on and off.

Might not be ideal for some, but it works for me and gives me the remote control I want.

1 Like
10

I use my Asus Router's built-in OpenVPN server capability to allow me to have full, secure, remote access to my home network. This allows me to connect my OpenVPN client on my phone when away from home and make changes, reboot (rarely), and even kick off a firmware update on my Hubitat Elevation hub.

1 Like
11

FWIW, we don't do any of this in developing the apps and drivers for this platform. Finding it hard to imagine that stats could help if a hub/driver/app is "misbehaving". If you know it's misbehaving, why not debug it? Sorry, just not believing the "enormous help" line at all, and that comes from having a lot of experience developing apps and drivers on and for Hubitat Elevation.

On top of that, we'd rather put our resources to work improving the platform for home automation users than putting effort into making it a "cooler developer's platform". We are happy that you and others can develop apps and drivers on the platform -- we do it every day ourselves. So we have a pretty good handle on what it takes. This is my polite and hopefully logical explanation of why this isn't going to happen.

2 Likes
12

from experience ... teams that build the platform generally have different level of access from users that build apps that run on those platforms. often leads to differing perspectives between platform teams and app dev teams. :slight_smile:

thank you.

13

With respect to apps and drivers we develop in the exact same environment that you do for Hubitat Elevation. We aren't using tools or methods not available to you.

14

SNMP for all the things!!! :smile:

2 Likes
15

that would be really cool.

16

I'm gathering by my searching that hub as a device probably won't every happen. What I've been looking for is a way to pull data of attached devices, like temperature sensors, out via SNMP to display in PRTG for graphing and visualisation.

1 Like
17

Have you seen this thread?

It may not be the PRTG you're used to, but if you need a graph....

1 Like
18

Looks like there'a a grafana plugin for prtg, so if @Theatreperson wants, he could just make a dashboard in Grafana that pulls in all the prtg data as well.

19

@asj I don't really see a point bringing PRTG data into yet another visualisation tool when PRTG does that just fine (for my needs). I can use that as a fallback option.

I'll have to try to digest the threads mentioned.
The Node-Red approaches seem to be the most logical for me as I don't have a coding background.

Thanks

20

figured it out with some PRTG folk help. Easier than I thought.
Maker API and then used the PRTG sensor HTTP XML/REST Value to query the API and node //attributes[name='temperature']/currentValue