[EM860P2-N TOUCH] Configuration created no devices

[funraa]

Is there an existing issue for this?

• [X] I have searched the existing issues

I'm having the following issue:

Integration is added to Homeassistant, configuration created, no devices or entities. Configuration failed. Retrying the configuration. Configuration failure... And so on.

I have following devices connected:

• [ ] ecoMAX 3xx series
• [X] ecoMAX 8xx series
• [ ] ecoMAX 9xx series
• [X] 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:

Logger: homeassistant
Source: /usr/src/homeassistant/homeassistant/runner.py:145
First occurred: 19:36:13 (23 occurrences)
Last logged: 19:43:05

Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/pyplumio/helpers/event_manager.py", line 75, in dispatch
    return_value = await callback(value)
                   ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/pyplumio/devices/ecomax.py", line 194, in _handle_ecomax_parameters
    description = ECOMAX_PARAMETERS[product.type][index]
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^
IndexError: tuple index out of range

Logger: pyplumio.connection
Source: runner.py:188
First occurred: 19:36:57 (74 occurrences)
Last logged: 19:44:07
Can't connect to the device, retrying in 20.0 seconds

My diagnostics data:

No device - no diagnostic data

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[denpamusic]

Hi,

Thank you for the feedback!

I'm sorry, but unless there's problem with physical connection (incorrect wiring, bad RS485 converter, etc.), error IndexError: tuple index out of range for ECOMAX_PARAMETERS dictionary, means that your specific ecoMAX model uses different parameters table which is not yet supported by PyPlumIO and by extension by this integration.

Could you please provide full model number so I can check?

[funraa]

Hi Thank you for your answer. My controller model is: ecoMAX 860P2-N TOUCH. My USB to RS485 converter is: Waveshare (fdti chip) and that's what I used. I bought an original Plum converter "ecoLINK2 USB/485" and connected it to the HA. The same mistakes. I checked communication between Waveshare and ecoLINK2 on the PC. There is communication both ways.

[denpamusic]

OK. I've never seen your model in use by any other users of this integration, so sadly I cannot confirm that it's compatible.

I've made this change to allow for more graceful handling of cases like yours. Now PyPlumIO will at least try to work with what parameters it knows, instead of completely giving up, when encountering unknown.

This change will be included into next stable release, which is scheduled for November, 15th. Please wait until this release and try again. Hopefully your controller just have some extra parameters on top, with the main parameters table intact.

Thanks again for the feedback and sorry for the inconvenience!

[funraa]

Thank you. I will test the new version and describe the result. Thank you also for changing the title, now it is more appropriate. Regards.

[funraa]

Hi I updated plum-ecomax to version 0.3.16 but unfortunately the same problem occurs. As I understand it, a parameter is needed for this to work: ECOMAX_PARAMETERS[product.type][index]. I could try to "pull it out", but I don't know how. Maybe data from the ecoNet module will be useful? Controller ID: ecoMAX860P2-N TOUCH Module A version:18.21.85 Module Panel version:18.11.7 Thank you again for your interest in my problem.

[denpamusic]

Sorry, I forgot to mention it here, this release 0.3.16 doesn't include changes for your device as it is still based on PyPlumIO 0.4.14. You should update to integration release 0.4.1 beta, once it comes out.

0.4.1 will be first release based on the PyPlumIO 0.5.x, which includes changes for your device and many-many more. As I expect things to break due to sheer amount of breaking changes introduced in PyPlumIO 0.5.x, I decided to do a tiny release, so that people can downgrade, if they encountered any errors.

Sorry for the inconvenience and please wait for 0.4.1, it will be out in a couple of days.

[funraa]

Thanks for the clarification.

[denpamusic]

You can now try to install v0.4.1-beta.2 by following this guide, but selecting v0.4.1-beta.2 instead of main when being prompted to select a version.

This version contains a more graceful handling of unknown parameters. It will warn you about unknown parameter in the log and continue, instead completely failing like previous versions did. Please note, that it doesn't necessary mean that everything will be working fine, because here we assume that Plum added new parameters onto regular EM860p parameters table instead of completely reinventing the whole table for your model.

If the whole parameters table is completely different from the one we know, it won't work. Then I'll need to develop a quick tool to obtain RESPONSE_ECOMAX_PARAMETERS message from your device and try to reverse-engineer it.

[funraa]

Hello Version v0.4.1-beta.2 found my furnace controller and integration with HA was successful. As you expected, this model, ecoMAX860P2-N TOUCH, is different from the others and the integration shows incorrect parameter readings. I am attaching the logs. If you create this tool "RESPONSE_ECOMAX_PARAMETERS" then of course I am ready to try to read these parameters. I'm sorry for such a late reply, but I'm at the furnace location once a week.

[funraa]

Logs home-assistant_plum_ecomax_2023-11-26T13-41-04.921Z.log config_entry-plum_ecomax-b38de036d136e9a0e458478a5ec6b4c1.json.txt

[denpamusic]

Thank you for heads up and especially for diagnostics!

Could you please clarify which parameters report incorrect values?

From your diagnostics, I see that a least some parameters, like "heating_target_temp" below, work fine.

{
  "heating_target_temp": {
    "__type": "<class 'pyplumio.structures.ecomax_parameters.EcomaxParameter'>",
    "repr": "EcomaxParameter(device=EcoMAX, values=ParameterValues(value=62, min_value=55, max_value=80), description=EcomaxParameterDescription(name='heating_target_temp', unit_of_measurement=<UnitOfMeasurement.CELSIUS: '\u00b0C'>, multiplier=1, offset=0), index=98)"
  }
}

edit. Sorry. replied before looking at the log. I now see timeout errors when trying to set parameters, this might potentially indicate, that SetEcomaxParameterRequest frame format might also be different, I'll investigate that and schedule error.

[denpamusic]

The following is mostly for myself, to keep track of the issue:

1. KeyError: 'water_schedule_switch' error from your log is now fixed in https://github.com/denpamusic/PyPlumIO/commit/99d6fcf770e383f1fb37507c8ecda9182745887e. This issue actually dates all the way back to PyPlumIO v0.2.35 and somehow has flown under the radar. Seems like not a lot of users use water heater schedule switch.

2. The parameter set timeout is actually related to this EM (ecoMAX) model not having frame 49 (FrameType.REQUEST_ECOMAX_PARAMETERS) in it's versioning table, which actually seems to be somewhat common with devices released after EM850:

   {
     "frame_versions": {
       "26": 0,
       "85": 15534,
       "84": 28411,
       "86": 34385,
       "54": 2,
       "56": 15,
       "57": 2,
       "61": 64682
     }
   }

   For comparison here's versioning table from EM850P2-C

   {
     "frame_versions": {
       "49": 140,
       "50": 140,
       "54": 1,
       "56": 122,
       "57": 7,
       "61": 3591,
       "80": 1,
       "81": 1,
       "82": 1,
       "83": 1,
       "92": 64421,
       "94": 0,
       "95": 126,
       "88": 22768,
       "62": 56014
     }
   }

That being said, this error by itself shouldn't actually impact the ability to set parameters. It only impacts ability to confirm that said parameters was correctly set.

One way to resolve this, would be to redo confirmation logic to re-request parameters manually after sending SetEcomaxParameterRequest instead of delegating this task to versioning handler.

This has drawback of requesting parameters twice on the devices that do have frame 49 in their versioning table, but I believe that will be acceptable price to pay, without getting complicated with different logic for different models, especially with the recent performance improvements.