Feature Requests

Maybe I found the culprit
The devices in question had authentication set to „none“
When I set it to „digest“ and leave the credentials empty instead, the device recovers automatically.

Hmmm. I think we may be conflating some behavior.

If the device is getting stuck (the status stays set to 'processing", then that's an indication that the plugin is getting hung up somewhere. In that case, it's right that the device's thread would never terminate. If a device is updated to "Error", then it should gracefully try to recover until the maximum number of retries is exceeded. The latter is expected, the former is probably the result of a bug.

I can't explain why selecting digest without credentials fixes the problem other than the fact that you've made a change to the device's configuration--in those instances, Indigo stops and restarts the device, which would also cause the old thread to terminate and a new thread to be created.

I will be adding validation rules that will not allow users to select authentication without adding credentials, so yours will be a short-lived solution.

Well I find a digest with empty credentials a valid setting. Some devices might have an internal default that is satisfied by something like that.

Could it be, that the timeout is only handled properly during authentication?
That was my speculation...

If you find that there's a need for digest authentication with no credentials, we'll continue to allow it.

I have tested the timeout feature here on a device that requires no authentication and one that requires it and both timed out as expected. In addition, I tested automatic re-enable Triggers on the devices and those functioned as designed as well. The plugin passes tests for no answer, invalid XML, invalid JSON, invalid credentials, no LAN, and no WAN among others. What may be happening with your source is that it's not providing a complete response. In other words, it's picking up the phone and saying hello, but not saying anything after that (or something like that).

You maybe right, that´s what I am suspecting as well.
Since you cannot control at what time the interruption takes place, it will be random anyways.
I realize that most of the time the interruption would happen during the inactive phase but it‘s not under anyones control.
Thanks for everything.
Have a nice Christmas!
Cheers

Wilhelm

What JSON url are you using currently?

I’ll set a device up pointing at your same URL and monitor it for a while.


Sent from my iPhone using Tapatalk Pro

Thanks, but what I am using are Yamaha Musiccast speakers in my internal WLan.
Sadly you will not be able to use them.

Ah, I presumed you were still on the stock market stuff.


Sent from my iPad using Tapatalk Pro

I spoke too soon.
After reducing the timeout to 5 seconds, 7 of my 11 GhostXML devices are hanging now ind the (red processing ) state and don‘t come back.

Sounds like there's a bug somewhere. Please turn on debugging and provide any errors that you see.

Hi Dave,

sorry for the delay, but I have been busy testing your plugin for several weeks...
First of all I downgraded to .36 and it has bee running for several weeks now without any hickups.
Two days ago I updated to .46 again.. During that time several devices went to a red status icon and froze at the "processing " state.
So I tried to take a debug log of such an incident.
Today I succeeded.

This is the log snippet I can give you:

Code: Select all

.52...

   GhostXML Debug                  ReturnCode: -9
   GhostXML Warning                [OTGW] curl error * Adding handle: conn: 0x7fdb63810a00 * Adding handle: send: 0 * Adding handle: recv: 0 * Curl_addHandleToPipeline: length: 1 * - Conn 0 (0x7fdb63810a00) send_pipe: 1, recv_pipe: 0 * About to connect() to otgw.voyager95.de port 80 (#0) *   Trying 192.168.1.52... . [Return code: -9
   GhostXML Debug                  [OTGW] Parse Error: No JSON object could be decoded
   GhostXML Debug                  [OTGW] jsonRawData {u'controlsp_description': u'Control setpoint', u'setpoint_description': u'Room setpoint', u'maxmod_description.ui': u'Max relative modulation level', u'flame_value': u'0', u'chwsetpoint_description': u'Max CH water setpoint', u'fault_description': u'Fault indication', u'modulation_value': u'0.00', u'boilertemp_description': u'Boiler water temperature', u'dhwtemp_value_dot_ui': u'48.05', u'otgw_firmware_name_dot_ui': u'Opentherm Gateway', u'chmode_description': u'Central heating mode', u'dhwmode_description': u'Domestic hot water mode', u'temperature_value': u'23.00', u'otgw_firmware_version_dot_ui': u'4.2.5', u'fault_description_dot_ui': u'Fault indication', u'setpoint_value_dot_ui': u'23.00', u'otgw_software_version': u'4.3', u'maxmod_value_dot_ui': u'100.00', u'controlsp_value_dot_ui': u'44.77', u'parse_error': True, u'deviceLastUpdated': u'01/12/2020 at 13:05', u'diag_value_dot_ui': u'0', u'dhwenable_description_dot_ui': u'Domestic hot water enable', u'otgw_software_name_dot_ui': u'Opentherm Monitor', u'temperature_description': u'Room temperature', u'fault_value': u'0', u'flame_value_dot_ui': u'0', u'diag_description': u'Diagnostic indication', u'otgw_firmware_version': u'4.2.5', u'dhwmode_description_dot_ui': u'Domestic hot water mode', u'returntemp_value_dot_ui': u'41.02', u'outside_description_dot_ui': u'Outside temperature', u'boilertemp_value_dot_ui': u'41.58', u'temperature_value_dot_ui': u'23.00', u'chmode_value_dot_ui': u'1', u'controlsp_description_dot_ui': u'Control setpoint', u'dhwenable_value': u'1', u'setpoint_description_dot_ui': u'Room setpoint', u'flame_description_dot_ui': u'Flame status', u'dhwsetpoint_description': u'DHW setpoint', u'dhwtemp_description_dot_ui': u'DHW temperature', u'diag_description_dot_ui': u'Diagnostic indication', u'returntemp_description': u'Return water temperature', u'otgw_time_dot_ui': u'2020-01-12 13:06:26 +0100', u'modulation_description': u'Relative modulation level', u'otgw_software_version_dot_ui': u'4.3', u'dhwtemp_value': u'48.05', u'dhwenable_value_dot_ui': u'1', u'otgw_software_name': u'Opentherm Monitor', u'outside_value_dot_ui': u'8.72', u'chmode_description.ui': u'Central heating mode', u'chwsetpoint_description_dot_ui': u'Max CH water setpoint', u'setpoint_value': u'23.00', u'controlsp_value': u'44.77', u'maxmod_value': u'100.00', u'deviceTimestamp': 1578830710.325386, u'maxmod_description': u'Max relative modulation level', u'temperature_description_dot_ui': u'Room temperature', u'outside_description': u'Outside temperature', u'boilertemp_value': u'41.58', u'dhwmode_value_dot_ui': u'0', u'outside_value': u'8.72', u'otgw_firmware_name': u'Opentherm Gateway', u'chwsetpoint_value_dot_ui': u'85.00', u'fault_value_dot_ui': u'0', u'dhwsetpoint_value': u'35.00', u'flame_description': u'Flame status', u'dhwsetpoint_value_dot_ui': u'35.00', u'chwsetpoint_value': u'85.00', u'chmode_value': u'1', u'deviceIsOnline_dot_ui': u'Processing', u'modulation_value_dot_ui': u'0.00', u'dhwtemp_description': u'DHW temperature', u'deviceIsOnline': True, u'modulation_description_dot_ui': u'Relative modulation level', u'returntemp_value': u'41.02', u'returntemp_description_dot_ui': u'Return water temperature', u'boilertemp_description_dot_ui': u'Boiler water temperature', u'diag_value': u'0', u'otgw_time': u'2020-01-12 13:06:26 +0100', u'dhwsetpoint_description_dot_ui': u'DHW setpoint', u'dhwenable_description': u'Domestic hot water enable', u'dhwmode_value': u'0'}
   GhostXML Warning                There was a parse error. Will continue to poll.



After that the GhostXML device stayed on that state, even when I restartetd the XML source again.
I hope this will help you a little bit.

I am happy with .36 for now, so there's now need for immediate action.
Thanks
Wilhelm

Thank you Wilhelm. I will take a look and see what I can uncover.

Dave

Hi Wilhelm -- this one was a little tricky to track down, but there was indeed a bug introduced between .36 and .46 which I think I have now corrected. When you have time, please try build 0.4.47 (build has not yet been released).

Basically, the bug was not allowing the parse_error bit to clear (even when the data were parsed correctly).

Thanks Dave,

but that wasn't it .
GhostXML now stays green - Processing.
There is no trigger about about the timeout and device still never recovers.
Here is the debug log:

Code: Select all

* About to connect() to otgw.voyager95.de port 80 (#0)
*   Trying 192.168.1.52...

   GhostXML Debug                  ReturnCode: -9
   GhostXML Warning                [OTGW] curl error * Adding handle: conn: 0x7fdc19025200 * Adding handle: send: 0 * Adding handle: recv: 0 * Curl_addHandleToPipeline: length: 1 * - Conn 0 (0x7fdc19025200) send_pipe: 1, recv_pipe: 0 * About to connect() to otgw.voyager95.de port 80 (#0) *   Trying 192.168.1.52... . [Return code: -9
   GhostXML Debug                  [OTGW] Parse Error: No JSON object could be decoded
   GhostXML Debug                  [OTGW] jsonRawData {u'controlsp_description': u'Control setpoint', u'setpoint_description': u'Room setpoint', u'deviceLastUpdated': u'01/13/2020 at 15:18', u'flame_value': u'0', u'temperature_value_dot_ui': u'23.47', u'fault_description': u'Fault indication', u'modulation_value': u'0.00', u'boilertemp_description': u'Boiler water temperature', u'dhwtemp_value_dot_ui': u'47.28', u'otgw_firmware_name_dot_ui': u'Opentherm Gateway', u'chmode_description': u'Central heating mode', u'dhwmode_description': u'Domestic hot water mode', u'fault_description_dot_ui': u'Fault indication', u'dhwmode_value.ui': u'0', u'otgw_software_version': u'4.3', u'controlsp_value_dot_ui': u'40.45', u'deviceLastUpdated_dot_ui': u'01/13/2020 at 15:15', u'setpoint_value_dot_ui': u'23.00', u'diag_value_dot_ui': u'0', u'dhwenable_description_dot_ui': u'Domestic hot water enable', u'otgw_software_name_dot_ui': u'Opentherm Monitor', u'temperature_description': u'Room temperature', u'fault_value': u'0', u'flame_value_dot_ui': u'0', u'diag_description': u'Diagnostic indication', u'returntemp_value': u'41.12', u'dhwmode_description_dot_ui': u'Domestic hot water mode', u'returntemp_value_dot_ui': u'41.12', u'outside_description_dot_ui': u'Outside temperature', u'boilertemp_value_dot_ui': u'42.03', u'otgw_firmware_version_dot_ui': u'4.2.5', u'chmode_value_dot_ui': u'1', u'controlsp_description_dot_ui': u'Control setpoint', u'dhwenable_value': u'1', u'setpoint_description_dot_ui': u'Room setpoint', u'dhwsetpoint_description': u'DHW setpoint', u'dhwtemp_description_dot_ui': u'DHW temperature', u'returntemp_description': u'Return water temperature', u'otgw_time_dot_ui': u'2020-01-13 15:19:37 +0100', u'modulation_description': u'Relative modulation level', u'otgw_software_version_dot_ui': u'4.3', u'dhwtemp_value': u'47.28', u'dhwenable_value_dot_ui': u'1', u'otgw_software_name': u'Opentherm Monitor', u'outside_value_dot_ui': u'10.11', u'chmode_description.ui': u'Central heating mode', u'otgw_firmware_version': u'4.2.5', u'setpoint_value': u'23.00', u'controlsp_value': u'40.45', u'diag_description_dot_ui': u'Diagnostic indication', u'deviceTimestamp': 1578925095.021134, u'temperature_description_dot_ui': u'Room temperature', u'outside_description': u'Outside temperature', u'boilertemp_value': u'42.03', u'flame_description_dot_ui': u'Flame status', u'parse_error': True, u'outside_value': u'10.11', u'otgw_firmware_name': u'Opentherm Gateway', u'fault_value_dot_ui': u'0', u'dhwsetpoint_value': u'35.00', u'flame_description': u'Flame status', u'dhwsetpoint_value_dot_ui': u'35.00', u'temperature_value': u'23.47', u'chmode_value': u'1', u'dhwmode_value': u'0', u'modulation_value_dot_ui': u'0.00', u'dhwtemp_description': u'DHW temperature', u'deviceIsOnline': True, u'modulation_description_dot_ui': u'Relative modulation level', u'returntemp_description_dot_ui': u'Return water temperature', u'boilertemp_description_dot_ui': u'Boiler water temperature', u'diag_value': u'0', u'otgw_time': u'2020-01-13 15:19:37 +0100', u'dhwsetpoint_description_dot_ui': u'DHW setpoint', u'dhwenable_description': u'Domestic hot water enable', u'deviceIsOnline_dot_ui': u'Processing'}
   GhostXML Warning                There was a parse error. Will continue to poll.
 

Dang. Thought I had it. The difficulty is that I'm trying to emulate the problem you're having and apparently haven't struck upon the right error yet. I have many test devices that create various types of errors and they're all clearing as expected. I'll continue to dig.