Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timeouts seting parameters using the service "set parameter" #59

Open
3 of 10 tasks
niq83 opened this issue Jan 3, 2024 · 3 comments
Open
3 of 10 tasks

Timeouts seting parameters using the service "set parameter" #59

niq83 opened this issue Jan 3, 2024 · 3 comments
Labels
bug Something isn't working

Comments

@niq83
Copy link

niq83 commented Jan 3, 2024

Is there an existing issue for this?

  • I have searched the existing issues

I'm having the following issue:

In a random way I get timeouts settting parameters using HASS service

I have following devices connected:

  • ecoMAX 3xx series
  • ecoMAX 8xx series
  • ecoMAX 9xx series
  • Expansion module B
  • Expansion module C
  • ecoSTER 200/ecoSTER Touch
  • ecoLAMBDA
  • ecoNET 300

I'm connecting to my devices using:

USB to RS-485 adapter

I'm seeing following log messages:

This error originated from a custom integration.

Logger: pyplumio.helpers.parameter
Source: custom_components/plum_ecomax/services.py:217
Integration: Plum ecoMAX (documentation, issues)
First occurred: January 2, 2024 at 4:08:33 PM (78 occurrences)
Last logged: 7:22:47 PM

Timed out while trying to set 'airflow_power_100' parameter
Timed out while trying to set 'airflow_power_50' parameter
Timed out while trying to set 'airflow_power_30' parameter
Timed out while trying to set 'fuel_feeding_pause_100' parameter
Timed out while trying to set 'fuel_feeding_pause_50' parameter

My diagnostics data:

config_entry-plum_ecomax-d50110c599e14ea3fc437c9d504fe209.json.txt

Code of Conduct

  • I agree to follow this project's Code of Conduct
@niq83 niq83 added the bug Something isn't working label Jan 3, 2024
@niq83
Copy link
Author

niq83 commented Jan 24, 2024

Hello,
I managed to check a bit more and it seams that the parameter is set but error messages are still generated.
I am not a programmer, but it looks like the timeout is generated waiting for some kind of confirmation.
What I am trying to do , is to control fan speed so that Oxigen level measured by a wide band lambda probe is kept to 10%
The oxigen is measured with controlduino and integrated to HomeAssistant

Thank You

@denpamusic
Copy link
Owner

Hi,

Thank you for the feedback and detailed description!

Sorry for not responding earlier, internet has been kinda flaky, I'm on a literal boat until early February, hence why so little work is being done on project :(

You're actually exactly right about Parameter.set() method waiting for confirmation here.

The issue is related to the way that this confirmation is achieved.
The ecoMAX (EM) device every status frame received from the EM contains, what I call a version table.
It contains frame type and frame version, when you change some parameters either on physical EM device itself or remotely via RS485, version for the respective frame is increased by one.

For example, for EM850p, this table might looks like this:

"frame_versions": {
  "49": 6,      // FrameType.REQUEST_ECOMAX_PARAMETERS
  "50": 6,      // FrameType.REQUEST_MIXER_PARAMETERS
  "54": 2,      // FrameType.REQUEST_SCHEDULES
  "57": 2,      // FrameType.REQUEST_UID
  "61": 49922,  // FrameType.REQUEST_ALERTS
  ...
},

If we change a parameter, we get new version table:

"frame_versions": {
  "49": 7,      // FrameType.REQUEST_ECOMAX_PARAMETERS
  "50": 6,      // FrameType.REQUEST_MIXER_PARAMETERS
  "54": 2,      // FrameType.REQUEST_SCHEDULES
  "57": 2,      // FrameType.REQUEST_UID
  "61": 49922,  // FrameType.REQUEST_ALERTS
  ...
},

Version number 7 for frame type 49 (FrameType.REQUEST_ECOMAX_PARAMETERS), tells us that EM acknowledges parameter change, so we can mark request as completed and not retry it again.

From your diagnostics data, your version table looks like this.

"frame_versions": {
  "26": 60490,
  "49": 264,
  "50": 264,
  "54": 1,
  "56": 10,
  "57": 4,
  "61": 1287,
  "80": 1,
  "81": 1,
  "82": 1,
  "83": 1
},

We can see frame type 49 (FrameType.REQUEST_ECOMAX_PARAMETERS) here again, which is good, but I believe on your device, when you change some parameter, version number for frame "49" doesn't increase. I've encountered at least two such devices during this project development. And since both were pretty new models, I think Plum changed the way that parameter changes are tracked.

You can check it by yourself, by downloading diagnostics data, then manually changing a parameter, downloading diagnostics data again and compare both version tables. If you see that version number for frame type 49 stayed the same, that means that your device tracks parameter change under some other frame number.

If you do this, it will also be very helpful, if you send these two diagnostic files to me at [email protected] so that I can take a look and hopefully figure out a way to track parameter changes on such devices.

Thanks beforehand and sorry for slow response!

@niq83
Copy link
Author

niq83 commented Feb 4, 2024

Hello,
I have checked and frame type is increasing vresion number when I change a parameter.
Thankk You

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants