The Current States are always listed in alphabetical order, but the State Variables are listed in, what, last update order, maybe?
It would be very helpful if the State Variables were also listed in alphabetical order. I'm forever "losing" one of these values, until I scan through them for the third time and finally find it.
Here's a little script for Greasemonkey, if you'd like to try out the sorting in your desktop browser. Make sure the IP address matches your networking scheme.
// ==UserScript==
// @name Hubitat Sort State Variables
// @version 1
// @grant none
// @include http://192.168.0.*/device/edit/*
// ==/UserScript==
function sortVars(id) {
var list, more, li, i;
list = document.getElementById(id);
more = true;
while(more) {
more = false;
li = list.getElementsByTagName("LI");
for(i = 0; i < li.length - 1; i++) {
if (li[i].innerHTML.toLowerCase() > li[i + 1].innerHTML.toLowerCase()) {
li[i].parentNode.insertBefore(li[i + 1], li[i]);
more = true;
}
}
}
}
sortVars("statev");
@darren I know its been several months, but I'm just now finding this on search.
I've loaded this script using TamperMonkey in Chrome. It shows installed and enabled but I'm still not seeing the list sorted. What is the trick to get this to work? I was assuming I just install the script and then refresh/reload the webpage. Is there more that needs to be done?
I just got it to work in TamperMonkey by changing the header part a little, added the description is was complaining about and then also edited the URL to be the exact IP. Something with the wildcard in the middle is not working, I would have to read up on it but this works for me:
// ==UserScript==
// @name Hubitat Sort State Variables
// @version 1
// @description Sorts State Variables in Hubitat Interface
// @grant none
// @include http://192.168.1.4/device/edit/*
// ==/UserScript==
@Darrren its working Great! I had no idea these kind of scripts were possible. Would something like this be able to sort the device list at the top of the Logs page? Thats another area of the HUbitat WebUI that's always bugged me (not sorted)
How true! Funny, I hadn't thought to sort that, but I do spend too much time hunting for devices in that list. It should be possible to sort that, though it will need some extra code since the list is dynamic, with new devices being added as they report in. Sorting that would be really useful, I'll take a look at it...
Here's a Greasemonkey script to sort the device list at the top of the Hubitat logs page. You might need to update the ip address to match your network, and TamperMonkey needs the exact ip address without that middle wildcard.
// ==UserScript==
// @name Hubitat Sort Log Devices
// @version 1.01
// @grant none
// @include http://192.168.0.*/logs*
// ==/UserScript==
function sortItems(id) {
var list, more, li, i;
list = document.getElementById(id);
more = true;
while(more) {
more = false;
li = list.getElementsByTagName("LI");
li[0].onclick = sortFilters; // if you click on the All button then it sorts the list of devices
for(i = 1; i < li.length - 1; i++) { // start at 1 to skip sorting the All button
if (li[i].innerText.toLowerCase() > li[i + 1].innerText.toLowerCase()) {
li[i].parentNode.insertBefore(li[i + 1], li[i]);
more = true;
}
}
}
}
function sortFilters() {
sortItems("filters");
sortItems("filtersPast");
setTimeout(sortFilters, 5000); // this regularly sorts the list of devices
}
setTimeout(sortFilters, 1000);
Thanks, thats also a great idea. Always has bothered me being in random order. Probably not random but maybe in the order they appear in the logs, not a useful order.
I did check the TamperMonkey docs and to use a wldcard in the middle it would need to be a full regex string, but I would rather specify the IP anyway I think. Tampermonkey • Documentation
@Darrren I have noticed something odd regarding the "Sort Log Devices" script. Most likely because of the 'dynamic' nature
Since its an active page continually updating with new entries, it somehow (timer?) re-sort the entries dynamically....which is nice if the page is visible it auto-updates without needing to refresh the page.
HOWEVER, I've notice if the page is hidden, it seems to stall the script from running. That appears to cause all the new log output to get queued and as the queue grows it slows down Hubitat. Making the page visible then dumps pages and pages of queued up log entries all at once clearing out the backed up queue.
Is there an option or setting in the scripting language to help with this? Maybe a way to disable the auto-update and just have it only run when I manually refresh the page?
This queuing issue that you're seeing is not related to the *monkey script. The deferring of log events happens due to a Chrome feature that pauses browser tabs that are in the background. If you were to temporarily disable Tampermonkey, you should still see this same queuing behavior when the logs tab is in the background. I see this behavior in Chrome for Android as well, where log events will come flooding in once I bring the browser back into the foreground.
Here's a page where someone is asking about the same issue, but for a stock ticker web app, And another page that talks about the issue, with some solutions.
Strange that this would cause your hub to slow down? The deferred websocket events (that the hub logs and dashboards use) shouldn't have any such affect that I can think of.
@darren thanks for the reply. I never noticed the queuing before. I typically keep a log page open all the time and it usually sits in the background. I didn't notice any issue until after enabling the monkey scripts. But I'm sure you're right, I just never noticed it or there is some other issue.
I can temorarily disable that particular script and the problem goes away. So even if it does still queue the log page normally, its not an issue unless the script is enabled.....or at least that seems to be what I'm seeing
In any case, the question still remains. Can I modify the script so its not auto-refreshing on a timer and just have it manually re-sort when I manually refresh the page?
Like @thebearmay said, you could disable the first setTimeout call, like such:
// setTimeout(sortFilters, 5000);
Btw, I'm using Firefox and it doesn't have this issue, as it seems to allow websockets to keep running in background tabs, so my logs and dashboards are always current, even with the monkey scripts enabled.
You could also try changing the timeout on that line to a longer value, like 75000. I'm thinking this might help, since I believe Chrome has a 60000ms timer that it uses for background tabs, and having the monkey script refresh the sort after that interval could solve a timing conflict, if that's the cause of the queuing issue.