@zxdavb I use a similar ser2net config.
Just wondering why the timeout 0?
By the way if anyone has the problem that ser2net is not ready for connections after a reboot on a rpi.
That is because it is starting before the network stack and cannot create the socket therefore.
I managed to fix that, Iāll try to post the fix I did tomorrow.
On another note: the nanocul with external antenna came in and the average rssiās dropped by 10 points with out tuning. After tuning they improved even a little more.
So Iām happy for now.
Next up experimenting with the bluetooth temperature sensor linked to a fake evohome sensor.
But first my bluetooth sensor config needs to be stable. need to keep the w.a.f. high, she is already not happy she cannot burn candles or place flowers with ice-cold water next to the controller without the heating going crazy.
All fine on my side. I still donāt have data from the UFH zones, but I am pretty sure this is a problem of reception (my dongle is too far from my UFH antenna).
All the rest seems to work as expected
Minor niggle, certainly not high priority, and I donāt know if the problem is in the integration or core.
If I edit an existing automation that calls evohome_cc.set_dhw_mode using HA Configuration->Automations (as opposed to a file editor), it loses settings for duration.
This is the code before:
- id: DHW_Fri-Sat
alias: DHW Late Night Friday Saturday
description: ''
trigger:
- platform: time
at: '22:55'
condition:
- condition: state
entity_id: water_heater.stored_hw
attribute: operation_mode
state: auto
- condition: time
weekday:
- fri
- sat
action:
- service: evohome_cc.set_dhw_mode
data:
mode: temporary_override
active: true
duration:
minutes: 15
mode: single
And then after editing
- id: DHW_Fri-Sat
alias: DHW Late Night Friday Saturday
description: ''
trigger:
- platform: time
at: '22:55'
condition:
- condition: state
entity_id: water_heater.stored_hw
attribute: operation_mode
state: auto
- condition: time
weekday:
- fri
- sat
action:
- service: evohome_cc.set_dhw_mode
data:
mode: temporary_override
active: true
mode: single
Source: /usr/local/lib/python3.9/site-packages/ramses_rf/protocol/message.py:373
First occurred: 06:00:23 (1 occurrences)
Last logged: 06:00:23
RP --- 10:051349 01:169176 --:------ 3EF0 006 0065100A0000 < AssertionError(0x65 > max value (0x64))
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/message.py", line 364, in _validate
result = PAYLOAD_PARSERS.get(self.code, parser_unknown)(
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/parsers.py", line 132, in wrapper
return fnc(*args, **kwargs)
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/parsers.py", line 1805, in parser_3ef0
mod_level = percent(payload[2:4], high_res=False)
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/helpers.py", line 134, in percent
assert int(value, 16) <= max_value, f"0x{value} > max value (0x{max_value:02X})"
AssertionError: 0x65 > max value (0x64)
What the the below means is that the USB is hearing the controller, but not the OTB - for 427 RQ packets, it heard only 321 of the corresponding RP packets (responses).
you can see below that the controller sent 2 RQs before sending a 22D9 packet (the USB dongle may not have heard the RP, but it seems the controller did), and then
the controller sent six 3220 packets in a row (i.e. it re-transmitted 5x before it gave up / got an RQ)!
My OTB is on a long wire, so Iāll move it as far away as I can from the boiler. I also ordered a 3 metre USB extension cable to move my USB stick away from my Zigbee and Z-Wave sticks. Iāve just done this.
without the heating going crazy.