Apologies if these questions were asked before as I am still relatively a noob on HE. I am trying to get the following answers / direction from staff or community members on the below. if these exist, can you kindly point me to where I can find them and if not will convert to feature requests:
1. Consolidated event subscriptions / schedules / cron entries:
Is there a way to get the entire schedule table for any given hub either as a report or as a crontable format?
I know I can see those as part of an app or device settings but am looking for a device-wide view as an example a table of the below would be most helpful, ideally with headings that are sortable but even if I can get to it via a hidden link that I can then parse as json, csv or the likes would be great:
appid, devid, eventmethod, schedule / cron format and perhaps last run status (success/fail)?
2. List of all hub push subscriptions / webhooks:
Similarly to #1 with perhaps a last_status, last_response fields would be great for troubleshooting purposes as well as validate / invalidate if hooks are properly subscribed to and/or duplicated or dead.
3. Device level debug switch:
It's great that we can set debug switches at an individual app and device. I use it a lot. But when things are steady-state, if I don't go to each and every device and app to switch it off, the log becomes rather noisy and code may suffer a nominal performance hit.
Would be great to know if one can set a 'global debug' switch to off that would override the individual debug settings as well as toggle it back to on to restore debug logging for all devices that have it set as 'on'
4. Log retention window:
How does one get a view of past logs beyond what is visible in the GUI? I am assuming (perhaps wrongfully) that the hub stores a longer trail than is displayed - is there a way of getting at it?
If the hub does not store a longer trail, is there a way to specify a hub-wide setting to the duration that the trail should be stored as a rolling window - e.g. 1 hour, 2 hours, 1 day, 1 week etc.
Of course some logic would need to be created to trim the history if local storage or log size exceed device thresholds but you get what I mean.
Thanks, Avi
1 Like
Staff will have to speak to whether any of the suggestions are possible, but basically none exist as-is, and I'm not aware of any easy workarounds for at least the first two items you mentioned.
For the third (enabling/disabling debug logging on devices), there is some hope: staff have teased that 2.2.5 will have an app that can automate the setting of preferences on any device. You could use this to turn on/off debug logging, for example. However, you would still have to select the device and the setting ("debug logging" isn't inherently part of this--just any device preference), plus some way to automate that (not sure they've disclosed exactly how that will work yet, but presumably you could either manually initiate it from the app UI or automate it with a virtual switch--we'll see). What it might help with is that you would no longer need to go into each device and do this manually. That being said, we've been told logging shouldn't really have an impact on app or driver code, so I wouldn't normally worry about this too much--but certainly logging only what you want is a good idea to make "Past Logs" more useful.
For log retention, I'm assuming you are already aware of "Past Logs." The live logs will hold things indefinitely as long as you keep the window/tab open, as far as I know (there may be a theoretical limit). Past Logs holds 256 KB of data unless that changed recently. However, I'm not sure if that is pruned in real time or as part of nightly or hourly maintenance (I think one of the latter). There is at least one third-party all that can connect to the logs "socket," which you could probably use to store that information elsewhere, but as far as I know, the hub itself doesn't--what you see is what there is. Limiting device and app logging is the best way to ensure that what you need is here...but I'm assuming you're aware of all of this and are asking for exactly that reason. 
1 Like
Robert (@bertabcd1234) - Thank you for the detailed response. No, I wasn't aware of the log's current size and surely the past log does not display the entire 256K as it seems much shorter in length than that? so how does one access the full 256K and who is the 3rd party that can pull it out or alternatively is there a get/post or other API that would allow me to script something to pull updates periodically as I don't always monitor for events and when I do, I am likely either too late to see the history or the displayable history is shorter than what can be looked at.
With respect to the other items - understood. How is best to get these requests looked at and evaluated for implementation by the dev team - are you taking it to them or is there a recommended process for me to go about it?
Thanks again, Avi
P.S. with the first two requests, I would imagine these are simple database queries or filesystem parse functions. If pointed the right direction, it shouldn't be too hard to implement a device or app that does that assuming it can attain the right read-only credentials to do so. I would imagine that there are plenty of scheduled jobs and hooks that are specific to the hub and its internal apps and processes and these can be easily filtered out using devid1 - again, a supposition but perhaps a means to get this evaluated as an easier task given the power of the community around the product who can make this happen and boost the product development bandwidth.
Staff are pretty active in the forums, so I imagine they will see your requests. But I wouldn't personally count on any major changes here; their priorities at the moment are usually focused on end-user experience. Development is just something power users can do for fun. But sometimes we get nice surprises. 
This is the app I was thinking of that can connect to the log websocket (I think that's how it works--I never looked into it much, and I don't use it): [BROKEN] Log Watchdog - Keep an eye on what's important in the log. It wouldn't do exactly what you want, I don't think, but it might show you one way you can access the logs yourself in real time and do with them as you please. Note that this is for live logs, not past logs. There is no way I know of (nor do I think they exist) to view anything beyond what "Past Logs" on the hub shows you without using something outside the hub, unless you use something like this to save live logs elsewhere.
Regarding the 256 KB, I'm not sure if that's the exact size now, but it was when that feature was introduced (but I don't remember any changes). My guess is that your size may vary due to exactly when this "pruning" takes place, which I also don't remember, and possibly how long each log entry is (I assume it strips entire log entries, not just a specific number of bytes, but again, I'm not sure).
