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

Can't connect to #135

Open
3 of 10 tasks
danielkovarik2 opened this issue Oct 9, 2024 · 3 comments
Open
3 of 10 tasks

Can't connect to #135

danielkovarik2 opened this issue Oct 9, 2024 · 3 comments
Labels
bug Something isn't working

Comments

@danielkovarik2
Copy link

Is there an existing issue for this?

  • I have searched the existing issues

I'm having the following issue:

Hello,

I am having issues with connecting to the boiler. Noticed initially in home assistant integration (timeouts) and after some digging I've found an error message in pyplumio.
Unknown sender type (80)

I have tried the script to get data from the ecomax (https://gist.github.com/denpamusic/5df805524738ea1bb9c00d25ed351c46) without any issues. Attaching file
ecomax_data.json

But when I tried to test another script I found in other issue here I got the unknown sender error again.
image

Would you please try to help me where should I look?

Tried:

  • scripts mentioned above
  • unplug the boiler from electricity
  • reconnect and rewire the ETH to RS-485 device (It's accessible via web config and communicating with the router w/o any issue)

Only change I made at home before this happened was that I changed the router (from old mikrotik to newer mikrotik) but it shouldn't be the issue I believe.

Thank you

My environment is:

env independent

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:

Ethernet/WiFi to RS-485 converter

I'm seeing following log messages:

No response

Code of Conduct

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

danielkovarik2 commented Oct 9, 2024

Update.

Tried to run the failed script couple times and I've got different results:

  1. Already mentioned pyplumio.exceptions.UnknownDeviceError: Unknown sender type (80)
  2. Different unknown sender pyplumio.exceptions.UnknownDeviceError: Unknown sender type (87)
  3. unknown frame type pyplumio.exceptions.UnknownFrameError: Unknown frame type (137)
  4. And actual response Got response (44 bytes): UIDResponse(recipient=<DeviceType.ALL: 0>, sender=<DeviceType.ECOMAX: 69>, econet_type=252, econet_version=50, message=b'\x000\x00\x0b\x00\x03\x00\x18\x111270B20\x00\x02\x00\x0eecoMAX860D3-HB', data={'product': ProductInfo(type=<ProductType.ECOMAX_P: 0>, id=48, uid='8921I88Z3ECHH24C000Z0', logo=48, image=2, model='ecoMAX 860D3-HB')})

These 4 randomly change

@denpamusic
Copy link
Owner

Hi,

Thank you for the feedback and sorry for delayed response.

Despite it's name UnknownDeviceError isn't really an error per se, it's serves more as a warning, that PyPlumIO encountered a frame from the unknown device, that it can't process. It is normally ignored by the AsyncProtocol and logged only on the DEBUG log level here. It doesn't affect operation of frame producer at all, as it simply continues onto next frame, that it hopefully can process.

The script from other issue that you've mentioned is simply too low level and doesn't have a mechanism to cope with it. It's why you only get issues with that script and not diagnostics.py which internally uses AsyncProtocol.

Here I updated it for you:

"""Collect a single frame and dump it on screen."""

import asyncio
import sys

import pyplumio
from pyplumio.const import DeviceType
from pyplumio.frames import requests, responses

# Set host and port here.
HOST = "localhost"
PORT = 8899


async def main() -> int:
    """Collect a single UID frame and dump it on screen.

    We'll use DummyProtocol here, since we'll need direct control over
    connection and access to a raw ecoMAX frame.
    """
    async with pyplumio.open_tcp_connection(
        host=HOST, port=PORT, protocol=pyplumio.DummyProtocol()
    ) as connection:
        print("Requesting UID from the ecoMAX...")
        await connection.writer.write(requests.UIDRequest(recipient=DeviceType.ECOMAX))

        print("Waiting for response...")
        while connection.connected:
            try:
                if isinstance(
                    (response := await connection.reader.read()),
                    responses.UIDResponse,
                ):
                    print(f"Got response ({response.length} bytes): {response}")
                    break
            except pyplumio.ProtocolError:
                # Continue reading next frame in case of protocol errors.
                pass


sys.exit(asyncio.run(main()))

Notice that now we catch pyplumio.ProtocolError and simply continue reading next frame instead of completely failing. Protocol errors to a certain extend can be safely ignored, since sometimes broken or unknown frames do happen in RS485 and should NOT be treated as unrecoverable.

@denpamusic
Copy link
Owner

denpamusic commented Oct 14, 2024

Hi again,

A couple of more things to note, that I've apparently missed in your issue description, due to being sick.
While UnknownDeviceError is probably not an error that is causing you a problem with timeouts, the presence of it can in fact indicate that you're getting malformed frames.

You see, PyPlumIO (PIO) frame reader uses fail-fast approach to error handling. In this approach we check a frames in order from least to most expensive checks. While this allows to fail frame early with least amount of wasted resources, this also makes it a bit harder to debug, since errors such as UnknownDeviceError can mean that PIO encountered frame from the unknown device, but it can also mean that whole frame was malformed. We just didn't bother to check checksum, since checksums are expensive and even if it's correct PIO wouldn't know what to do with frame from the unknown device anyways.

Since you've indicated in your issue description that you've only got ecoMAX connected to the network and nothing else, PIO shouldn't have encountered any unknown devices. So it this case the real issue is probably stems from PIO getting malformed frames from your device, which means there's possibly issue with your HW (converter settings or even RS485 wires not being properly attached). I'd start debugging this issue from hardware standpoint first.

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