I am a simple man - feature request

Isn't this similar to the approach of using groups with on/off optimization and running the rule a couple of times? @RobinWinbourne

also, the developer tag that you have means you are an hubitat developer? If so, can you tell me why my feature request haven't been implemented yet in the code before, it it because it is complex to do or simply because it's not a priority?

That just means he develops apps for Hubitat it doesn't mean he works for Hubitat.

5 Likes

He isn't a developer for Hubitat the company. That said, your feature request is 1 of thousands. Not all requests can be implemented. 1st they have to make sense in the grand scheme of things as well as the technical ability to implement, as well as fall into a priority list. Just because it's requested doesn't mean we get it...

2 Likes

Hubitat staff members have a little shield icon next to their forum handles. The rest of us are users and donā€™t speak on behalf of the company. However @JasonJoel is probably right:

My $0.02, as someone with literally zero computer coding knowledge. For them to add what youā€™re asking might be easy, it might not be. Since I have no idea, I try not to assume that any requests I make are easy to implement.

2 Likes

So, I implemented the following:

  • created 7 groups of around 4-5 devices each
  • disabled on/off optimization and enabled metering, 1000ms
  • created a simple rule that on button press, turns on twice each of the groups with 3 second wait between each group. group1 on, 3sec, group2 on, 3sec... group7 on, 6sec.... group1 on, 3sec, group 2 on, 3sec, group 7 on.
  • created a simple rule just like the above but does the reverse, it turns off, on button hold.

It is working. Seems to be hold by wires but it is working.

  • I had to disable metering because I noticed that sometimes the dashboard would display the wrong status for the lamp, for instance it would display as being on, but it was actually off. The device status would read on, so this is seems like a bug in hubitat, as the device has the right status but somehow the dashboard icon has a different one. I saw this happening with more than one device.
  • I also had to put the metering time to 1000ms as it seemed more consistent when the rule was running.

I would like to experiment more, for instance, I would like to create an icon on the dashboard to refresh the status of the lights, I mean, to read them from the device and update the icons accordingly. Is this possible? how?

In support of your perception that the Hubitat UI doesn't reflect some Device status correctly, I've observed that it often doesn't update in real time. Whether that's a 'bug' or a 'feature' I suppose is for the suits to claim. (NOTE: Since you asked, I really don't think this is something we can 'fix' ourselves.)

For instance, it bothers me that you can be looking at the Triggers section of a RM rule, where it shows a condition as [F] (false) that you know has since become [T] (true), and the only way to make the verbiage change is to leave (click "Done") and then return to edit the rule.

Guess I've become accustomed to the instant status updates of my other favorite rule engine, Multi-Hub Reactor, but I know it took a lot of doing on that developer's part to include in his UI. Maybe the guys at Hubitat will consider this as a 'feature request'.

Regardless, congratulations on your progress! And thanks for sharing the results.

1 Like

The only portion of the hub UI that is realtime dynamic in the way you imply is the Device state on the right side of a device page. The RM UI can be brought up to date by hitting refresh on some pages, or Refresh Action List on the actions page. You don't need to leave and return.

3 Likes

In that case, I vote for a [] REFRESH AUTOMATICALLY checkbox in certain places, such as the Settings ā–ŗ Hub Variables list, where it makes sense users might want to see real time updates to those values. It can be a real help in troubleshooting a workflow.

EDIT: It would also be instructive to show, under Apps, the term (DISABLED) in red, next to those items you have clicked the [X] on to pause. Those red marks disappear otherwise after clicking the X, toggling the "Disabled" column to invisible. (NOTE: I've included this with another thread on the topic in question.)

Thanks @bravenel !

1 Like

This is not possible with our current UI framework, and could lead to infinite refresh loops. We've put in Refresh buttons where it might be relevant. We would like to move to a more dynamic UI framework, but this will take some time and a great deal of effort.

This is not possible in the current UI. The disabled column does exactly that, and the app is not able to update its displayed name, by virtue of the fact that it is disabled.

2 Likes

Makes sense, and thanks for explaining. Also explains why the 'X' column automatically makes itself visible on every visit to the "Apps" panel whenever one or more app (parent or child) is currently Disabled.

I came to the latter realization only after posting my "Feature Request" above (sorry).

Perhaps, but puts everything in one place rather than a fragmented set of groups and automatons.

The developer tag is a legacy from when I released a bunch of drivers ages ago... I will turn that tag off as I've not released anything for ages (and most of what I released has been improved on by other users anyway)!

1 Like