-
Notifications
You must be signed in to change notification settings - Fork 8
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
Comments
Hello, Thank You |
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 The issue is related to the way that this confirmation is achieved. 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! |
Hello, |
Is there an existing issue for this?
I'm having the following issue:
In a random way I get timeouts settting parameters using HASS service
I have following devices connected:
I'm connecting to my devices using:
USB to RS-485 adapter
I'm seeing following log messages:
My diagnostics data:
config_entry-plum_ecomax-d50110c599e14ea3fc437c9d504fe209.json.txt
Code of Conduct
The text was updated successfully, but these errors were encountered: