Irregular connection issues using Touch V3.10d

[ahornung]

Are there known issues querying the JSON API, especially using the Touch panel of a Oekofen Pellematic Compact running V3.10d ?

I'm querying the JSON API regularly, and over 24h there are multiple time intervals where there is no data returned. E.g. manually running "curl" on all data regularly returns incomplete (broken) data, while querying all sections separately returns most (but not all) data.

Examples:

curl http://IP:PORT/PASSWD/all
curl: (18) transfer closed with 4338 bytes remaining to read

curl http://IP:PORT/PASSWD/pe1
{
   "pe1":{
      "L_temp_act":"680",
      "L_temp_set":"80",
      "L_ext_temp":"-32768",
      "L_frt_temp_act":"1269",
      "L_frt_temp_set":"80",
      "L_br":"false",
      "L_ak":"false",
      "L_not":"true",
      "L_stb":"true",
      "L_modulation":"0",
      "L_uw_speed":"0",
      "L_state":"99",
      "L_statetext":"Aus",
      "L_type":"9",
      "L_starts":"362",
      "L_runtime":"372",
      "L_avg_runtime":"61",
      "L_uw_release":"638",
      "L_uw":"0",
      "L_storage_fill":"3603",
      "L_storage_min":"400",
      "L_storage_max":"4300",
      "L_storage_popper":"29",
      "storage_fill_today":"15",
      "storage_fill_yesterday":"16",
      "mode":"1"
   }
}

curl http://IP:PORT/PASSWD/ww1
curl: (18) transfer closed with 506 bytes remaining to read

A few hours later, querying all data work again. From my logs, it affects mostly the "ww1", "hk1", "pe1", or a combination of them.

The heater is connected via cable (all cables and router already swapped and tested, with no success). Known bug?

[bertrandgorge]

Have a look at https://github.com/stawen/okovision - the code is not particularly clean, but it works well...!

[ahornung]

Thanks for the hint, I was not even aware of that project.
I'm already using the solution described here:
https://nc-x.com/oekofen-spy
https://www.haustechnikdialog.de/Forum/t/242695/Monitoring-einer-Oekofen-Pelletronic-Touch-Heizungssteuerung
(documentation only in German, unfortunately)

The nice thing is that it simply queries the JSON data in a lightweight python script, puts all data into an Influx database, and the monitoring then runs in Grafana and can be flexibly adjusted.

For some reason, however, the JSON interface regularly has dropouts on my boiler or touch control. I don't think it's related to the python / influx / grafana framework, because it also happens when manually querying the JSON interface in a browser or via curl.

[tnijboer]

Thanks for that tip, didn’t know oekofen-spy yet.

but aren’t you hitting the rate limit? Had drop-outs too when I called more than once a time a 10 seconds if I’m correct.

Did you have oekofen-spy running at the time you did the manual request?

[ahornung]

No, it does not look like I'm hitting the rate limit (should be 2.5s). oekofen-spy is running every 2 minutes, and the behavior is identical if I'm using manual requests (or even just query via a browser once every hour).

Hitting a rate limit returns an error 401 with error message(curl - v):

curl -v http://IP:PORT/PASSWD/pu1
*   Trying IP:PORT...
* TCP_NODELAY set
* Connected to IP (IP) port PORT(#0)
> GET /PASSWD/pu1 HTTP/1.1
> Host: IP:PORT
> User-Agent: curl/7.68.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 401 Unauthorized
< Date: Sat, 20 Nov 2021 11:24:01 GMT
< Content-length: 37
< 
* Connection #0 to host 192.168.1.40 left intact
Wait at least 2500ms during requests

Whereas the erroneous return looks like this:

curl -v http://IP:PORT/PASSWD/all
*   Trying IP:PORT...
* TCP_NODELAY set
* Connected to IP (IP) port PORT(#0)
> GET /PASSWD/all HTTP/1.1
> Host: IP:PORT
> User-Agent: curl/7.68.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Sat, 20 Nov 2021 11:26:23 GMT
< Content-length: 4357
< 
* transfer closed with 4357 bytes remaining to read
* Closing connection 0
curl: (18) transfer closed with 4357 bytes remaining to read

Interestingly, if I quickly query the same "broken" URL again, it returns the 401 rate limit error - but never the complete data until it's back in a "working" state again after a few hours.

[ahornung]

With the graphic analysis and partially recorded data, I was able to find some correlations:


(red / green in above plot: hk1.L_flowtemp_act/set; plot below: temperatures in buffer with bright red warm water at highest temp. sensor).

"hk1" data is not available via JSON when radiator heating is off during night, but available during daytime and night when the outside temperatures are low enough (reduced heating temperature).
"ww1" data is not available outside the configured warm water heating times (probably the set temperature is also at some low value).
Querying "all" via JSON only works when the sub-part data are all available and work, e.g. during daytime and warm water heating times.

Since the data is present in the CSV files and the Oekofen app, it looks like a bug in the JSON part of the V3.10d control panel software.

[PeterFausH]

i may confirm same behaviour in Touch V3.00b 04112019 Version.

[tLoether]

It seems that the issue is caused by German umlauts (äöü) in the JSON response. In my case http://IP:PORT/PASSWD/all and http://IP:PORT/PASSWD/hk1 did not work at all until I changed hk1.name from 'Heizkörper' to 'Heizkoerper'.

The phenomenon that hk1 data is not available on nights with higher outside temperature is probaby caused by the 'ü' in hk1.L_statetext='Außentemp über Heizgrenze absenken'. Also pe1.L_statetext='Zündung' breaks the JSON interface.
And there are probably more state texts with umlauts.

A simple workaround is to change the display language to English.

[ahornung]

Great finding, thanks! Indeed, I had a gut feeling about the name fields and already cleared all of them, but haven't thought about the varying "statetext" fields.

It's all working exactly as you described: adding an Umlaut to a name field breaks the corresponding JSON block, removing them and changing the language of the heating control to English makes everything work as expected.

Slightly related, oekofen-spy is now available here: https://gitlab.com/p3605/oekofen-spy