Cannot connect to Remo E lite
Closed this issue · 16 comments
I failed to connect to "B route service" through Nature Remo E lite.
I got following log message:
2022-11-08 16:08:28.561 WARNING (MainThread) [custom_components.echonetlite.config_flow] _<IP Address>_- Unable to resolve the manufacturer name - 262. Please report the manufacturer name of your device at the issue tracker on GitHub!
2022-11-08 16:08:28.767 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry Remo E lite for echonetlite
With debug mode I got following log message:
2022-11-08 16:20:00.510 DEBUG (MainThread) [custom_components.echonetlite] ECHONETlite platform is already started.
2022-11-08 16:20:00.511 DEBUG (MainThread) [custom_components.echonetlite] Starting ECHONETLite Generic instance for 5-255-1 at _<IP Address>_
2022-11-08 16:20:00.511 DEBUG (MainThread) [custom_components.echonetlite] UID for ECHONETLite instance at _<IP Address>_ is 0001060000000000000098f4ab1fa7f8.
2022-11-08 16:20:00.633 DEBUG (MainThread) [custom_components.echonetlite] ECHONETLite Message Received from _<IP Address>_ - Raw data is b'\x10\x81\x00\t\x05\xff\x01\x05\xff\x01r\x01\x80\x010'
2022-11-08 16:20:00.634 DEBUG (MainThread) [custom_components.echonetlite] ECHONETLite Message Received from _<IP Address>_ - Processed data is {'EHD1': 16, 'EHD2': 129, 'TID': 9, 'SEOJGC': 5, 'SEOJCC': 255, 'SEOJCI': 1, 'DEOJGC': 5, 'DEOJCC': 255, 'DEOJCI': 1, 'ESV': 114, 'OPC': [{'EPC': 128, 'PDC': 1, 'EDT': b'0'}]}
2022-11-08 16:20:00.634 DEBUG (MainThread) [custom_components.echonetlite] ECHONETLite Message Received from _<IP Address>_ - tid_data is {}
2022-11-08 16:20:00.714 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry Remo E lite for echonetlite
Can you run the following command in Python command line?
Please provide the execution log if possible.
- bash
pio install pychonet
python3 -m asyncio
- python
from pychonet.lib.udpserver import UDPServer
from pychonet import ECHONETAPIClient as api
udp = UDPServer()
loop = asyncio.get_event_loop()
udp.run("0.0.0.0", 3610, loop)
server = api(udp)
server._debug_flag = True
await server.discover("_<IP Address>_")
Thank you for your reply!
I ran your command and got following log message:
>>> await server.discover("_<IP Address>_")
ECHONETLite Message Received from _<IP Address>_ - Raw data is b'\x10\x81\x00\x01\x0e\xf0\x01\x05\xff\x01r\x03\x8a\x03\x00\x01\x06\x83\x11\xfe\x00\x01\x06\x00\x00\x00\x00\x00\x00\x00\x98\xf4\xab\x1f\xa7\xf8\xd6\x04\x01\x05\xff\x01'
ECHONETLite Message Received from _<IP Address>_ - Processed data is {'EHD1': 16, 'EHD2': 129, 'TID': 1, 'SEOJGC': 14, 'SEOJCC': 240, 'SEOJCI': 1, 'DEOJGC': 5, 'DEOJCC': 255, 'DEOJCI': 1, 'ESV': 114, 'OPC': [{'EPC': 138, 'PDC': 3, 'EDT': b'\x00\x01\x06'}, {'EPC': 131, 'PDC': 17, 'EDT': b'\xfe\x00\x01\x06\x00\x00\x00\x00\x00\x00\x00\x98\xf4\xab\x1f\xa7\xf8'}, {'EPC': 214, 'PDC': 4, 'EDT': b'\x01\x05\xff\x01'}]}
ECHONETLite Message Received from _<IP Address>_ - tid_data is {}
True
@nao-pon looks like its some sort of echonetlite hub in its own right. The 0xD6 instance list EPC is returning 0x05,0xFF,0x11 which is controller class. That is a real can of worms, would need special discovery logic to iterate each echonetlite device that is under the control of the hub. In fact, would be a very interesting experiment to see if you can directly control connected devices via the hub IP address using the relevant codes etc..
Controller class 0xFF is missing from EPC_CODE in const.py so chances are populating that would help for now.
Also, I’m guessing the manufacturers table needs updating too 😄
@yhi264 It seems that only the 0x05,0xFF classes are exposed. You can get more information with the following python command.
from pychonet.lib.udpserver import UDPServer
from pychonet import ECHONETAPIClient as api
udp = UDPServer()
loop = asyncio.get_event_loop()
udp.run("0.0.0.0", 3610, loop)
server = api(udp)
server._debug_flag = True
await server.discover("_<IP Address>_")
await server.getAllPropertyMaps("_<IP Address>_", 0x05, 0xFF, 0x01)
server._state.get("_<IP Address>_")
However, there is a possibility that useful data cannot be obtained according to the specification.
@scottyphillips Yes, indeed the device in question acts as a hub. It would be nice to bridge the ECHONET Lite packets of the devices connected to it by parroting back, but I don't know for sure unless I check the actual data.
I have updated pychonet master with 0x05, 0xFF controller class.
My assumption is this particular gadget is acting as a bridge between Wi-SUN + Wi-Fi enabled echonetlite nodes to consume pretty similar energy management data as to what Home Assistant itself is consuming using this component. I have done some reading of the specification appendix, but it is unclear to me if you can use the controller as a 'relay' to other echonetlite nodes.
@nao-pon Thank you for your additional reply!
It's log messages:
>>> await server.discover("_<IP Address>_")
ECHONETLite Message Received from _<IP Address>_ - Raw data is b'\x10\x81\x00\x01\x0e\xf0\x01\x05\xff\x01r\x03\x8a\x03\x00\x01\x06\x83\x11\xfe\x00\x01\x06\x00\x00\x00\x00\x00\x00\x00\x98\xf4\xab\x1f\xa7\xf8\xd6\x04\x01\x05\xff\x01'
ECHONETLite Message Received from _<IP Address>_ - Processed data is {'EHD1': 16, 'EHD2': 129, 'TID': 1, 'SEOJGC': 14, 'SEOJCC': 240, 'SEOJCI': 1, 'DEOJGC': 5, 'DEOJCC': 255, 'DEOJCI': 1, 'ESV': 114, 'OPC': [{'EPC': 138, 'PDC': 3, 'EDT': b'\x00\x01\x06'}, {'EPC': 131, 'PDC': 17, 'EDT': b'\xfe\x00\x01\x06\x00\x00\x00\x00\x00\x00\x00\x98\xf4\xab\x1f\xa7\xf8'}, {'EPC': 214, 'PDC': 4, 'EDT': b'\x01\x05\xff\x01'}]}
ECHONETLite Message Received from _<IP Address>_ - tid_data is {}
True
>>> await server.getAllPropertyMaps("_<IP Address>_", 0x05, 0xFF, 0x01)
ECHONETLite Message Received from _<IP Address>_ - Raw data is b'\x10\x81\x00\x02\x05\xff\x01\x05\xff\x01r\x03\x9d\x04\x03\x80\x81\x88\x9f\n\t\x80\x81\x82\x88\x8a\x93\x9d\x9e\x9f\x9e\x03\x02\x81\x93'
ECHONETLite Message Received from _<IP Address>_ - Processed data is {'EHD1': 16, 'EHD2': 129, 'TID': 2, 'SEOJGC': 5, 'SEOJCC': 255, 'SEOJCI': 1, 'DEOJGC': 5, 'DEOJCC': 255, 'DEOJCI': 1, 'ESV': 114, 'OPC': [{'EPC': 157, 'PDC': 4, 'EDT': b'\x03\x80\x81\x88'}, {'EPC': 159, 'PDC': 10, 'EDT': b'\t\x80\x81\x82\x88\x8a\x93\x9d\x9e\x9f'}, {'EPC': 158, 'PDC': 3, 'EDT': b'\x02\x81\x93'}]}
ECHONETLite Message Received from _<IP Address>_ - tid_data is {}
True
>>> server._state.get("_<IP Address>_")
{'instances': {5: {255: {1: {157: [128, 129, 136], 158: [129, 147], 159: [128, 129, 130, 136, 138, 147, 157, 158, 159], 138: 0, 131: None}}}}, 'manufacturer': 262, 'uid': '0001060000000000000098f4ab1fa7f8', 'discovered': True}
My assumption is this particular gadget is acting as a bridge between Wi-SUN + Wi-Fi enabled echonetlite nodes to consume pretty similar energy management data as to what Home Assistant itself is consuming using this component. I have done some reading of the specification appendix, but it is unclear to me if you can use the controller as a 'relay' to other echonetlite nodes.
I originally had Remo E lite as a device to access B route service, and I heard that it is a device device compatible with ECHONET lite, so I was hoping to utilize it as a Wi-SUN Bridge to acquire power information with Homeassistant. However, it seems to be difficult to acquire power information through ECHONET lite from Remo E lite.
I think @nao-pon is working on a wi-sun gateway.
https://github.com/nao-pon/python-echonet-lite
@yhi264 have you directly integrated any echonetlite devices previously into HA?
@yhi264 have you directly integrated any echonetlite devices previously into HA?
I have integrated "Sharp KI-HS50" with your component.
@yhi264 , @scottyphillips Thanks!
The ECHONET Lite specifications define the specifications that bridge the data of devices connected to the controller class. But unfortunately Nature Remo Elite doesn't seem to have that feature.
Page 643, 3.6.2 Requirements for controller class
556ページ、3.6.2 コントローラクラス規定
@nao-pon @scottyphillips
That's bad news:-(
The problem is in Remo E lite, not your component.
Anyway, thank you so much to take time for this issue!
OK, I updated MANUFACTURERS
list.
I'll close this for now, but it seems that the implementation of the controller can control the device connected to it, so if you find such a controller, please let us know!