Picture speak a 1000 words if I go to look at past logs i see nothing, but if I view the page source I can see the logs in there...
See picture below you can see in the outline what apears to be what should be the logs
_ have coppied the entire source for the page if you would like to see dont know where I would upload to :-)_
Thanks
M
Judging from the screenshot it appears potentially a device name or app name has an unclosed HTML tag causing it to break the rendering.
Is there a way to flush the logs??
and do you wand me to send the source for that page, so you can examine a did a save of the entire page source??
and thanks for the quick response, sofar lov'in HE
M
I am happy to look at it, but I won't be able to fix it if it is what I suspect. Key is finding the offending device or app name and fixing that.
There is no way to purge the past logs, they rotate over time. Something could also be logging out with rogue html element causing the issue.
This shouldn't happen with built in apps and drivers. I'd start with a list of custom drivers or apps and see if any of them are logging out HTML for some reason, and its malformed.
If it is a 3rd party app or driver, you can disable it or remove it to restore functionality once the log rotates out.
Thanks for the responce...
Any reason as to why you could not add a clear/save log as in almost 99% of programs, systems people use, is there a technical reason?? as it would be better to clear the logs as I could do for any program/os for a program and try and recreat the issue, can this be added as a feature 
I am using nothing that has not been used by any one else on the forum the only custom device is the
HTTP Insteon Switch/Dimmer which talks to the homebridge stuff... and it would be hard to turn that off as I would still have to wait like you said for the log to roll, and seeing that I don't have alot going on as i just got started and testing I dont thing the log is gonna roll anytime soon :-(, pluse if I was to say work on a driver and did some hoe mess the HTLM, it really would be a pain if I kep having to wait for the log to roll to be able to fix my issue.
The file if you want to look at is on onedrive link below:
https://1drv.ms/t/s!AgPZnaScK47uqzOOTZBSS_Fzgjy8
thanks
Stab in the dark here...but what are your "Office Lights". They seem to be generating a strange debug log with an http error included.
The office lights are Insteon Dimmers...
which as I mentioned above are created in HE by using HTTP Insteon Switch/Dimmer driver code,
which inturn talks to the Homebridge-platfor-insteonlocal which is running on a Rpi 3 B+
all works well the device once instanciated in HE works flawlessly...
I do see that weird stuff with the verizon in it which seems out of sorts, and may be the offending issue, as I have not seen it again, it might have occured when I had invalid credentials in my config.json that the Homebridge/insteonlocal uses but the logs seem consistant after that issue is if I can get rid of just thoes line I will not be able to tell if that was it was....
as if I send missformed HTML when I am testing how is one ever suppose to debug if they cant clear out the offending log errors or get to them to see what the error is
Thanks for looking, I guess as Patrick says I will have to wait till the logs roll, when that will happen only the shadow knows 
You seem to have quite a bit of sonos activity so it might be sooner that you think. Check it again in a couple of hours.
Yahtrue, is funny as i am not even touch any of my Sonon stuff so there is alot of chatter in the logs for a system I am not inter acting with, I think is is just polling all my devices well a 1/3 of them as I have only included the ones close to me so when testing I can see or do some stuff...
Like dim the lights, play a particular play list, light the fire and pour the wine ... ROTFL
It is truely what HA is all about keeping the Wife happy.... WAF
I will keep yah posted when it roll if thats what it was..
You can keep logging open as well to see things in real time. Device event tables are available too. Past logs is just what happened vs logs which is real time.
thanks for the info..
Yah it seems that all is well in OZ, as all the controls seem to work fine and the logging in real time is fine as it doesnt seem to throw up when I use any of the commands.
I do have a question if when running the logs live and you have misformated HTML or such will it throw an error in the live log or just not show or will it do the same it does for the past logs and go all haywir...
so how much of the logs do you keep for past logs a few hours is it # line based??
M
Size based (256K)
The number of lines and the timeframe depend on what is in the log data.
As promised the log has rolled and all is good...
If it happens again and you see similar debug logs, I would recommend you reach out to @SmartHomePrimer or @cwwilson08 as they might have better insight into why this output is gunking up the logs.
I shall, I wish there was a way just to save and clear the logs as then I could see a smaller subset of the errors..
Maybe in the furure, as do't know why they don't have that ability now, maybe som technical issues
Not something I've encountered. Doubtful that the config.json formatting would be at all responsible. You'd get an error in Node.js, not the HE logs. Do let use know if the issue occurs again and you can eliminate it by removing the Insteon driver from HE.
As I have to agree with you on that if I explain a bit better when adding the credentials to the config.json I left the [ ] around the UID amd Password, thus causing an authentication error which was showing up, in addition to that I also had coppied the password string into the device Id so that did not help so some how with all that going on I got a respone that looked like this as I have not see this again did show 2x in the logs as I manually parsed
"2019-01-07 12:44:07.002\tDEBUG\tdev|35|Office Lights|resp = [mac:null, ip:5cf28c15, port:50, headers:[HTTP/1.1 200 OK:null, Server:nginx, Date:Mon, 07 Jan 2019 17:44:06 GMT, Content-Type:text/html; charset=utf-8, Transfer-Encoding:chunked, Connection:close, Expires:Mon, 07 Jan 2019 17:54:06 GMT, Cache-Control:max-age=600, X-Frame-Options:DENY], body:<meta http-equiv="refresh" content="0;url=http://searchassist.verizon.com/main?ParticipantID=euekiz39ksg8nwp7iqj2fp5wzfwi5q76&FailedURI=http%3A%2F%2Fnull%3A80%2Flight%2Fnull%2Fon&FailureMode=1&Implementation=&AddInType=4&Version=pywr1.0&ClientLocation=us"/><script type="text/javascript">url="Verizon | Unable to find "null"";if(top.location!=location){var w=window,d=document,e=d.documentElement,b=d.body,x=w.innerWidth||e.clientWidth||b.clientWidth,y=w.innerHeight||e.clientHeight||b.clientHeight;url+="&w="+x+"&h="+y;}window.location.replace(url);, header:HTTP/1.1 200 OK","Server: nginx","Date: Mon, 07 Jan 2019 17:44:06 GMT","Content-Type: text/html; charset=utf-8","Transfer-Encoding: chunked","Connection: close","Expires: Mon, 07 Jan 2019 17:54:06 GMT","Cache-Control: max-age=600","X-Frame-Options: DENY",", status:200]",
so I am gonna say that this and the other similar line was the culprit... now why I got that respose, could be my inate abilities to find all the little secret combinations to break everything ROTFL
What are the chances....I have this exact same ability.
Hey guys.
Sorry to put my pain-in-the-arse security hat on, but if I'm reading this right... the assumption is that the logs display page isn't correctly escaping output before throwing it to a web page. That's a bit of a security no-no - it's the classic attack vector for a cross-site scripting attack.
At it's worse... if it's not escaping anything at all - then potentially user inputs from anywhere (anything that generates inputs that might be logged - weather services, apps that read inbound email subjects to speakers over TTS, etc), could potentially deliver a payload that could do anything in the context of the web admin portal. Calling javascript to delete devices would spring to mind immediately as a nuisance-y thing, but the possibilities are endless.
To do a proper job, you really need ruthless input validation as well, but given a lot of the inputs into HE come from devices and automated systems, explicit output escaping for ALL data is pretty much mandatory, I'd think.
If I get any time tonight, I'll see if I can create an obvious test-case to cause some proper mischief. I always find that focuses minds nicely.
-- Jules
Download the Hubitat app
