My logs recently started throwing this warning message. I haven't changed anythign on my dashboards in the last little while. Any ideas?
Ok, I narrowed it down to my @bptworld Hub WatchDog Tiles. I doubt it's anything to do with the app itself, likely the way I'm presenting the information on the dashboard?
Here's the settings for those tiles:
A Dashboard tile has too many letters, which includes Formatting and CSS characters. Grand total must be less than 1024.
There's no Harm.. it is just a warning, but it does mean words, letters or formatting have been lopped off.
Interesting... so if I disable one of those tiles. I still get the warnings. If I disable the other one, I still get warnings. If I disable both then I get no warnings. So both of them are problematic but what would be the character issue? There's no special formating on the tiles and names of the tiles and the value displayed are quite short...
I think @bptworld would be better able to answer that. I don't know what he has 'hidden' in the formatting to get things centered, etc.
1 Like
The warning in the logs references "list1" which is likely this "list 1" attribute of the Hub WatchDog Device:
My guess is that since I installed Hub Watchdog a few days ago, the measurements have gathered and now there are too many in the device for the dashboard eventhough it's only referencing the attribute "lastdatapoint1"?
I think you're right, but it's an App I never used, so I can't be helpful 
I simply recognized "1024" and knew what that meant. 
2 Likes
The warning is meaningless. This has been brought up many times. When selecting a device to display on a dashboard, the Dashboard app 'sees' all attributes. Not just the one selected. So even though you haven't selected 'list1', it sees it and will display that warning that it is too big.
This again is a major issue with how the Dashboards work.
1 Like
Thanks. I should have searched more but I was just kind of documenting my findings as I went and then it was late and I went to bed.
Since you've come across this issue before you likely know whether there is a way to hide that warning from the logs? I searched and coulding find anything so my guess is no?
It's a dashboard log warning, the only thing to be done is to not have any attributes with more than 1024 characters. Log messages are not written to the database, so they are "harmless".
@bptworld, in light of all the recent changes in version 2.2.3, is it worth reevaluating this?
How far does the attribute need to truncated to get it within 1024 characters? How many watchdog reports would we loose? Right now, I am getting a log entry every 5 seconds. While I am only keeping 100 of them, it still feels like unnecessary work on the hub.
First to admit I am over my head here.
What changes related to this are you talking about?? I don't know of any.
This is still an issue with HE ... not with my or any other app. If your not trying to display the attribute in question, then the HE dashboard should ignore it and not throw a warning. This is only something that HE can fix/change.
2.2.3 is going down as the version that is saving HE for a lot of folks, and the primary difference is truncating logged events per device from 1,000 to 100.
I was in this category and exploring other options, but now with those changes, I am refocusing on HE. I have not crashed in nearly 2 weeks.
One thing it has taught me is to aggressively go after anything that is logging like crazy or to stop unneeded zwave triggers (turn light on, but it's already on) (Z-Wave storms - looks like HE Hub's fault?)
In any case, Hub Watchdog can get going and log like mad. Which is now on my bad list. 
It can log as much as it likes...
and also...
and the answer was very clear.
Use or not use whatever you like, that's the beauty of choice but please don't spread rumors without doing your homework. There is absolutely no reason (or proof) that Hub Watchdog causes any slowdowns. Period.
Log entries that appear in Logs screen (live or past) are relatively harmless. The real resource hogs are devices that produce lots of events or state changes. Best example is a power measuring outlet - it can log several measurements a minute, every minute. Make it a dozen outlets, and it starts adding up.
2 Likes
dude, defensive much?
the comment you just liked from @gopher.ny just debunked the comment that logging items are harmless. His phase is relatively harmless. However if your hub is failing regularly, any change - no matter how small - is critical. And if the primary difference in 2.2.3 is to cut logs to a tenth the size, pretty sure logs are bad.
Rather than get so defensive and attack, clearly something lots of folks have brought up, why not an option to truncate within the bounds of the dashboard?
We're talking logs vs. events and states here. Different stuff.
Saving an entry into log has a very small impact. Having logs screen open in browser window has much larger impact. It a Schrodinger's cat thing - an observer looking at the logs might kill the kitty 
But it is still a piece of text that gets saved on a flash drive and sent over network, not a big deal on its own. Sure, you can have an app generating ten log lines a second and a dozen browser windows open at the same time. That will have an impact, yes, but I wager it's a rare scenario.
A device generating event and multiple states changes along with it, now that's a different beast. Having apps triggered by event, with each app having code to execute and database to query, can get resource intensive and cause a slowdown. Event a simple insert of event or device state into a table means database has to process indexes. With database size reduction, we hope to have the entire thing cached in memory, thus speeding up processing.
None of this applies to the logs. They are stored in a plain text file, and are not a part of the database.
4 Likes
Thank you.
Try to blame my app for your problems... yes, I get defensive.
You clearly have no idea what your talking about.
I'm done beating a dead horse here...
Have a nice day!
