Here is another log file. This includes a couple of times when I clicked the “refresh” button in the TCC setup screen.
Yes, the devices are linked by ID not by name (or room). The TCC ID is stored in the vera thermo device’s altId entry. There is one other possibility. I made a change that breaks out of the translation loop at the first match thinking that the remaining compares would be a waste of time. However, if you have old devices from a previous install this may break. I have removed the break so the highest number device’s translation will be used (the last one added). See if this change solves your problem.
That doesn’t seem to have helped. Same error code/status. And now 2 of my 3 thermostats lost their setpoints & current temperatures (not that they were correct anyway). They are just shows 0.0F. The 3rd one still shows a setpoint and temperature, but it is from hours ago (it is not what the actual thermostat is currently showing).
If you want me to try, I can uninstall the app, and then re-install it fresh with you updated files from earlier today to see if that changes anything. I can also try reinstalling your files from yesterday to see if they come back.
Please note, if you don’t think it is going to help, I don’t want to do it. This is because if I delete and add new devices, I will have to reconfigure all of my logic in PLEG to reflect the new devices. But if you do think it will help, I have no problem doing that.
No, you dont need to uninstall. I don’t see the call to getStatus actually return. Please ssh back to your vera and grep the log file for ‘nil’ and see if the plugin crashed. I see the getStatus return in the bad credentials test but not in the good credentials path. I can also add more log statements and post a new version for you. Thanks for helping sort this out!!
Here is a log file for 'nil".
Try this version and grab a HNYWL TCC log.
Hmm, let me see what my logs are telling me. I just noticed it hasn’t responded since I loaded the files.
Uploaded the new file. Same visual results from the Vera devices. New log file attached.
Hmmm, I see the status string from the HTTP response but the json decode does not seem to return. We are using a different json decoder and my unit test might not use vera’s json library. I’ll try to get that fixed and see if that is the problem.
I believe UI7/MCV has opted for dkjson… I’ve observed logs cycle on my system but it is definitely crashing out the system as I’m seeing restarts.
I changed over to dkjson to see if this helps… Looks good so far but I’ll wait through a couple of refreshes
50 12/22/15 21:24:57.290 luup_log:245: HNYWL TCC: STATUS HEAT: 2 <0x2ca82680>
50 12/22/15 21:24:57.291 luup_log:245: HNYWL TCC: STATUS COOL: 2 <0x2ca82680>
50 12/22/15 21:24:57.291 luup_log:245: HNYWL TCC: SYETEM SWTITCH POS: 2 <0x2ca82680>
50 12/22/15 21:24:57.292 luup_log:245: HNYWL TCC: LOAD: 127.5 <0x2ca82680>
50 12/22/15 21:24:57.293 luup_log:245: HNYWL TCC: Heat Next / Scheduled : 25 / 66 <0x2ca82680>
50 12/22/15 21:24:57.309 luup_log:245: HNYWL TCC: Getting local temperature scale <0x2ca82680>
50 12/22/15 21:24:57.319 luup_log:245: HNYWL TCC: updated json= { "full": 1, "version": "*1.7.730*", "model": "Sercomm NA900", "zwave_heal": 1, {removed by Cuda}
50 12/22/15 21:24:57.495 luup_log:245: HNYWL TCC: Got local temperature scale <0x2ca82680>
50 12/22/15 21:24:57.496 luup_log:245: HNYWL TCC: convertTemp: from F to F <0x2ca82680>
50 12/22/15 21:24:57.497 luup_log:245: HNYWL TCC: convertTemp: from F to F <0x2ca82680>
50 12/22/15 21:24:57.497 luup_log:245: HNYWL TCC: convertTemp: from F to F <0x2ca82680>
50 12/22/15 21:24:57.498 luup_log:245: HNYWL TCC: convertTemp: from F to F <0x2ca82680>
50 12/22/15 21:24:57.510 luup_log:245: HNYWL TCC TRACE: honeywellToTime tccTimeNumber=25, <0x2ca82680>
50 12/22/15 21:24:57.511 luup_log:245: HNYWL TCC TRACE: honeywellToTime return retTime=6:15 AM, <0x2ca82680>
50 12/22/15 21:24:57.512 luup_log:245: HNYWL TCC TRACE: honeywellToTime tccTimeNumber=25, <0x2ca82680>
50 12/22/15 21:24:57.514 luup_log:245: HNYWL TCC TRACE: honeywellToTime return retTime=6:15 AM, <0x2ca82680>
50 12/22/15 21:24:57.517 luup_log:245: HNYWL TCC TRACE: refreshTUI return <0x2ca82680>
50 12/22/15 21:24:57.518 luup_log:245: HNYWL TCC TRACE: refreshStatus return statText=Successful refresh., statResult=1, <0x2ca82680>
50 12/22/15 21:24:57.519 luup_log:245: HNYWL TCC TRACE: refreshAllStatus return statText=Successful refresh., statResult=1, <0x2ca82680>
50 12/22/15 21:24:57.519 luup_log:245: HNYWL TCC TRACE: updateCredentials return <0x2ca82680>Well, the good news is the parser works using dkjson. Bad news is it’s still crashing. Once crashed it starts init all over again.
50 12/22/15 21:25:04.100 luup_log:245: HNYWL TCC: task Clearing...
Info Viewer ajax error - possibly malformed XML received:
500 - Internal Server Error
50 12/22/15 21:29:38.401 luup_log:245: HNYWL TCC TRACE: init lul_device=245, <0x2c3e6680>
50 12/22/15 21:29:38.403 luup_log:245: HNYWL TCC TRACE: init return <0x2c3e6680>
50 12/22/15 21:29:39.101 luup_log:245: HNYWL TCC TRACE: updateCredentials <0x2cfe6680>
50 12/22/15 21:29:39.101 luup_log:245: HNYWL TCC: task Honeywell TCC: Authorizing credentials... <0x2cfe6680>
50 12/22/15 21:29:39.103 luup_log:245: HNYWL TCC: task Clearing... <0x2cfe6680>
50 12/22/15 21:29:39.113 luup_log:245: HNYWL TCC TRACE: retrieveLoginCookie username={removed by Cuda}, password={removed by Cuda}, <0x2cfe6Yeah, I think it is the \r\n sequence in the json response that is causing issues. I filtered them out and it seems to work. But if dkjson does not have the issue and is the preferred decoder (I thought it was json-dm, which I do use in my unit test). Odd thing is that when I load the test response from a file it works, when I load from a string it fails…
Do you have a suggestion as to which fix to take ?
Try this change
Edit: Just realized you’re grabbing the the scale… Can’t tell I’m tired…
No dice.
I’m trying to recall as I remember seeing threads about the changeover of JSON parsers. Let me look research before I send us spinning in the wrong direction.
As for loading from a file or a string, either way it should work. Does the string simply indicate it’s malformed ?
[quote=“mikee, post:414, topic:185402”]Yeah, I think it is the \r\n sequence in the json response that is causing issues. I filtered them out and it seems to work. But if dkjson does not have the issue and is the preferred decoder (I thought it was json-dm, which I do use in my unit test). Odd thing is that when I load the test response from a file it works, when I load from a string it fails…
Do you have a suggestion as to which fix to take ?[/quote]
Argh, OK back to the original json parser. Try this.
Yes! Everything is working. Is there anything that may not be working now that I should look for? (i.e. re-authentication issues as discussed earlier)