Get the Escea python libraries working with my fireplace, etc.

[pa-wills]

Requires me to get the python library working (https://github.com/snikch/escea). Once that's done, presumably the HomeAssistant Integration ought to be pretty simple (https://github.com/snikch/climate.escea).

Hopefully this will work, because the alternative is going to be using scraping, or - worst case - SDR.

[pa-wills]

I have the library working now. Requires python3, which my mac does not ship with by default.

[pa-wills]

So, I put the components onto my Pi, and this is what I get:

2019-09-05 04:37:52 WARNING (zeroconf-Engine) [zeroconf] Choked at offset 126 while unpacking b'\x00\x00\x84\x00\x00\x01\x00\x01\x00\x00\x00\x02\x00\x00\x00\x0c\x00\x01\x00\x00\x00\x0c\x00\x01\x00\x00\x00x\x00\x19\x06escea-\x05_http\x04_tcp\x05local\x00\x06escea-\x05_http\x04_tcp\x05local\x00\x00!\x00\x01\x00\x00\x00x\x00\x12\x00\x01\x00\x00\x00P\x0bescea-79658\x0bescea-79658\x00\x01\x00\x01\x00\x00\x00x\x00\x04\x00\x00\x00\x00' 2019-09-05 04:37:52 WARNING (zeroconf-Engine) [zeroconf] Exception occurred: Traceback (most recent call last): File "/usr/local/lib/python3.7/site-packages/zeroconf.py", line 666, in init self.read_others() File "/usr/local/lib/python3.7/site-packages/zeroconf.py", line 724, in readothers type, class, ttl, length = self.unpack(b'!HHiH') File "/usr/local/lib/python3.7/site-packages/zeroconf.py", line 674, in unpack info = struct.unpack(format, self.data[self.offset : self.offset + length]) struct.error: unpack requires a buffer of 10 bytes 2019-09-05 04:39:02 ERROR (MainThread) [homeassistant.helpers.entity] Update for climate.escea79658 fails Traceback (most recent call last): File "/usr/local/lib/python3.7/site-packages/escea/fire.py", line 71, in send data, = sock.recvfrom(1024) socket.timeout: timed out

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 261, in async_update_ha_state await self.async_device_update() File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 441, in async_device_update await self.hass.async_add_executor_job(self.update) File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run result = self.fn(*self.args, **self.kwargs) File "/config/custom_components/escea/climate.py", line 193, in update self._state = self._fire.status().state File "/usr/local/lib/python3.7/site-packages/escea/fire.py", line 83, in status return StatusResponse(self.send(StatusRequest())) File "/usr/local/lib/python3.7/site-packages/escea/fire.py", line 73, in send raise ConnectionTimeout escea.error.ConnectionTimeout

I am wondering whether the network traffic is being blocked. When I ran it for the first time on my MBA the system asked for permission to send the traffic outbound. I think I will just try the escea library on the pi and establish that that at least works, and then reinvestigate the Custom Component.

[pa-wills]

So, I have run it with a test script from the Pi. It just doesn't work every few times. What needs to happen here is - a retry loop. For that I will need to fork the escea library.

This is basically working now though.

[pa-wills]

Specifically, I need to experiment with the timeout value, and retries inside his send() in his escea library. Essentially, we're making UDP more connection-oriented. Hilarious.

[pa-wills]

I am running it now. And it's been up and not restart since 2356 yesterday. It's working perfectly..... Weird.

Something else I noticed yesterday. If I instantiate the fire class with the IP (192.168.0.129), and then manipulate the set temperature - it works perfectly. I built a test harness - test2.py - which establishes this.

I've turned-up the logging somewhat as well. Shows the discovery, and shows it working ok. So, maybe what I was seeing on Thursday was actually a glitch?

[pa-wills]

..... It's quite unreliable though. Broken half the time. I reckon I am going to need to use a RF blaster instead.