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

Unknown SenseMe device model - H Series #3

Closed
Nick-Adams-AU opened this issue Apr 9, 2020 · 8 comments
Closed

Unknown SenseMe device model - H Series #3

Nick-Adams-AU opened this issue Apr 9, 2020 · 8 comments

Comments

@Nick-Adams-AU
Copy link

Hi Mike,

Thanks for your work. I'm on 2.0.5 and have the below error in my HA logs:

Discovered unknown SenseME device model='FAN,HAIKU,HSERIES'

Is the H-series fan not supported at the moment?

@mikelawrence
Copy link
Owner

mikelawrence commented Apr 9, 2020

This is just a warning; your H-series fan should be working. I added this warning so I could get people like you to send me information on models I didn't know about. Have you tried controlling your fan and light (if installed) in Home Assistant?

The funny thing is I have an older H Series fan (2015-2016) and its model string is 'FAN,HAIKU,SENSEME'. When I look at the website I don't see any reference to H Series. There is only Haiku and Haiku L.

Either way I will add this new model string to the list of known models so you will stop receiving this warning. I update this when you get back to me about the fan/light working?

@Nick-Adams-AU
Copy link
Author

Thanks for that. I had a dig through the code and can see what you are saying.

The interesting thing is that when I saw these warnings, I was struggling to get the fans to turn up in HA. There was also this error about aiosenseme:

2020-04-09 13:10:16 ERROR (MainThread) [aiosenseme.discovery] Broadcaster task error Traceback (most recent call last): File "/usr/local/lib/python3.7/site-packages/aiosenseme/discovery.py", line 219, in _broadcaster endpoints = await self._create_endpoints() File "/usr/local/lib/python3.7/site-packages/aiosenseme/discovery.py", line 200, in _create_endpoints allow_broadcast=True, File "/usr/local/lib/python3.7/asyncio/base_events.py", line 1256, in create_datagram_endpoint raise exceptions[0] File "/usr/local/lib/python3.7/asyncio/base_events.py", line 1240, in create_datagram_endpoint sock.bind(local_address) OSError: [Errno 98] Address in use

I can't work out why the address is already in use as it happens when I restart the docker container so nothing should be running.

@mikelawrence
Copy link
Owner

mikelawrence commented Apr 9, 2020

So your fan was detected and should be working.

The other error is a different animal. When I switched to the new asyncio library (aiosenseme) which I also wrote I had to modify how discovery UDP packets were received. Specifically I switched to the asyncio protocols. As far as I can tell for UDP sockets binding to all addresses on a machine using "0.0.0.0" does not work. In seems to only listen on the first interface it finds. So I added a listener on each interface found by the ifaddr library. It fixed my problem of only listening on the first detected address but added other problems like yours. Your error is from the library trying to listen on an interface that does not allow a socket bind like a VPN connection that is not connected. If the error occurs before a valid interface then discovery may not listen to all interfaces. I'm going to add a try/except on this section to detect an OSError and just output a debug log message.

I'll try to make these changes in the next 24 hours.

@Nick-Adams-AU
Copy link
Author

Nick-Adams-AU commented Apr 9, 2020

What you describe above sounds like what I am seeing. I have multiple interfaces including physical (ethernet + wifi) and virtual (docker + vlan). When I restart my HA instance, either the fans are detected quickly (about 25% of the time) or they are never detected.

That said, I have built applications that listened on UDP:0.0.0.0 on all interfaces. I can't see why you need to specify an interface when the OS should determine this by its routing table - 0.0.0.0 matching all interfaces.

@Nick-Adams-AU
Copy link
Author

This might not be your issue. I think I've been bitten by this bug:

home-assistant/core#32992 (comment)

Give me a few days to see if things settle down when I fix the Docker issue.

@mikelawrence
Copy link
Owner

mikelawrence commented Apr 11, 2020

So I probably misspoke about listening on all interfaces at "0.0.0.0". It is also possible that the socket is listening on all interfaces but the discovery broadcast ends up going out only one interface.

I have updated the aiosenseme library to support the slightly different model string. I have also added a bit more exception handling which should prevent an error on one interface stopping discovery on all interfaces. I also updated this SenseME integration to require the new library.

From your previous post it looks like like Home Assistant could be running twice in a Docker environment. That definitely would be a problem for my library. Discovery broadcast responses will only sent to one instance basically starving out the other instance if you don't get another error like "OSError: Address in use".

All said, I would give the new SenseME integration a try since I did find a problem that could cause lost discovery responses.

@Nick-Adams-AU
Copy link
Author

So the issue Errno 98] Address in use did relate to a change with Docker and not SenseMe.

I haven't had any issues with the SenseMe changes and everything has been working well. Thanks for your work!

@mikelawrence
Copy link
Owner

Glad to here its working now!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants