Hi David,
Thanks for your response. This morning I’ve tried repositioning the antenna and restarted again. This has solved all my issues. I don’t really understand it because I promise you this antenna has remained in the exact same position for more than a year.
Anyway… Even the service missing error is gone now as well and the entities are no longer unavailable.
I’ll keep you posted if it happens again.
Fresh first install, latest stable.
When adding this to configuration.yaml then validation results in an endless spinning circle
evohome_cc:
serial_port:
port_name: /dev/serial/by-id/usb-Texas_Instruments_TUSB3410_Boot_Device_TUSB3410-if00-port
# baudrate: 57600
packet_log:
file_name: packet.log
rotate_bytes: null
rotate_backups: 7
Looking for evohome in the logs gives no result, except for the custom components warning
Edit:solved it, mistyped the serial port device
Is there a way to silence the QoS spam?
2022-04-24 12:48:22 WARNING (MainThread) [ramses_rf.protocol.transport] PktProtocolQos.send_data(sent=0008|RQ|13:051953): boff=3, want=0008|RP|13:051953, tout=2022-04-24T12:48:22.132: QoS: IS_EXPIRED (giving up) (2/2)
Everything is working fine for me but this is unnecessarily clogging up my HA logs.
In configuration.yaml:
logger:
logs:
ramses_rf.protocol.transport: error
Not ideal, because it will stop other warnings from ramses_rf.protocol.transport.
Thanks. Are there any warnings I would need to watch out for that would require action if everything is functioning fine already?
Just returning to this integration and noticed there used to be updates to this thread every few days but now a month apart.
Did I miss something - is it still evolving, brief pause, no longer maintained or just stable and everyone is happy?
Not much has happened from your point of view, but I have made > 200 commits to ramses_rf since v1.29.1… One advantage is a much more rigorous test suite.
I am hoping to release a new evohome_cc to take advantage of all the changes soon… Unfortunately, here will be breaking changes., so I was happy to wait until spring…
Many improvements, for example:
That’s great news on two counts. Firstly the existing users must be happy as there are no ‘problem’ posts and secondly it’s maintained still and evolving with new features.
Many thanks for the enormous amount of work you have, and still are putting into this integration.
Kevin
Hi,
I’m trying to use ramses_rf directly from python with a nanoCUL with evofw3, but it doesn’t find me anything (I have the controller / display and two TRV actuators), while if I connect directly on the serial I see that the messages are exchanged. I have tried on both Ubuntu and Windows…
I also tried to add the config.json, but I’m not sure I wrote it right, my devices are 01:244016, 04:030560, 04:030562 if you can help me, thanks
These are some messages I have seen directly through the serial port
15:04:12.075 -> 031 I --- 01:244016 --:------ 01:244016 1F09 003 FF08D4
15:04:12.075 -> 031 I --- 01:244016 --:------ 01:244016 2309 006 0004B0010708
15:04:12.075 -> 031 I --- 01:244016 --:------ 01:244016 30C9 006 000AC6010AF5
15:04:41.846 -> 038 I --- 04:030562 --:------ 04:030562 30C9 003 000AC6
15:04:41.846 -> 038 RQ --- 04:030562 01:244016 --:------ 1F09 001 00
15:04:41.846 -> 031 RP --- 01:244016 04:030562 --:------ 1F09 003 0007A8
15:04:42.939 -> 038 RQ --- 04:030562 01:244016 --:------ 1F09 001 00
15:04:42.939 -> 031 RP --- 01:244016 04:030562 --:------ 1F09 003 00079E
15:06:15.791 -> 050 I --- 04:030560 --:------ 04:030560 30C9 003 000AF7
15:06:15.826 -> 050 RQ --- 04:030560 01:244016 --:------ 1F09 001 00
15:06:15.826 -> 031 RP --- 01:244016 04:030560 --:------ 1F09 003 0003FC
15:07:57.995 -> 031 I --- 01:244016 --:------ 01:244016 1F09 003 FF08D4
15:07:58.065 -> 031 I --- 01:244016 --:------ 01:244016 2309 006 0004B0010708
15:07:58.065 -> 031 I --- 01:244016 --:------ 01:244016 30C9 006 000AC6010AF7
15:09:41.866 -> 038 I --- 04:030562 --:------ 04:030562 30C9 003 000AC6
15:09:41.866 -> 038 RQ --- 04:030562 01:244016 --:------ 1F09 001 00
15:09:41.866 -> 031 RP --- 01:244016 04:030562 --:------ 1F09 003 0004C4
15:09:42.820 -> 038 RQ --- 04:030562 01:244016 --:------ 1F09 001 00
15:09:42.855 -> 031 RP --- 01:244016 04:030562 --:------ 1F09 003 0004BA
15:11:44.017 -> 031 I --- 01:244016 --:------ 01:244016 1F09 003 FF08D4
15:11:44.052 -> 031 I --- 01:244016 --:------ 01:244016 2309 006 0004B0010708
15:11:44.052 -> 031 I --- 01:244016 --:------ 01:244016 30C9 006 000AC6010AF7
15:13:46.604 -> 031 I --- 01:244016 --:------ 01:244016 3B00 002 FCC8
15:14:41.803 -> 038 I --- 04:030562 --:------ 04:030562 30C9 003 000AC6
15:14:41.837 -> 038 RQ --- 04:030562 01:244016 --:------ 1F09 001 00
15:14:41.837 -> 031 RP --- 01:244016 04:030562 --:------ 1F09 003 0001E0
15:14:42.506 -> 038 RQ --- 04:030562 01:244016 --:------ 1F09 001 00
15:14:42.506 -> 031 RP --- 01:244016 04:030562 --:------ 1F09 003 0001DB
15:15:30.033 -> 031 I --- 01:244016 --:------ 01:244016 1F09 003 FF08D4
15:15:30.067 -> 031 I --- 01:244016 --:------ 01:244016 2309 006 0004B0010708
15:15:30.067 -> 031 I --- 01:244016 --:------ 01:244016 30C9 006 000AC6010AF7
Thanks
Could you show us the CLI command you’re using? something like:
python client.py -g monitor /dev/ttyACM0 -o packet.log
Show us any output from that, and include a copy of your config.json.
That’s not right?
Hi, thankls for reply.
I use python client.py -c config.json monitor /dev/ttyUSB0 -o packet.log' I tried now also with '-g' but I don't get the message, in the packet.log I have only 2022-06-10T10:31:28.635705 # ramses_rf 0.20.0`
and in the terminal
10:31:41.159 It is strongly recommended to provide a known_list, and use it as a whitelist (device_id filter), configure: enforce_known_list = True
10:31:42.114 Not using any device filter: using a known_list (as a whitelist) is strongly recommended)
10:32:27.246 PktProtocolQos.send_data(sent=7FFF| I|63:262142): boff=3, want=7FFF| I|63:262142, tout=2022-06-10T10:32:27.244: QoS: IS_EXPIRED (giving up) (24/24)
this is the config.json instead
{
"schema": {
"controller": "01:244016",
"zones": {
"00": {
"heating_type": "radiator_valve",
"sensor": "04:030562",
"devices": [
"04:030562"
]
},
"01": {
"heating_type": "radiator_valve",
"sensor": "04:030560",
"devices": [
"04:030560"
]
}
}
}
}
I also tried without using it, but it’s the same thing
Yes that’s correct, i get it (if i use serial terminal, not with python) when i move the setpoint on the TRV
Don’t use a config file for now, just use:
python client.py -ge monitor /dev/ttyUSB0 -x "RQ 01:244016 1F09 00"
NB: with the
-x, you should expect an immediate response from the controller.
What command are you using where you have success listening directly to the serial port? I assume you are on Linux, not windows?
Please don’t use the master branch for now, instead:
git checkout 0.19.2
What version of evofw3 are you using?
re: ‘that’s not right’ - I mean that, in a healthy system, I wouldn’t expect the TRVs to do this:
038 RQ --- 04:030562 01:244016 --:------ 1F09 001 00
Still nothing…
client.py: Starting ramses_rf...
12:40:48.367 enable_eavesdrop enabled: this is discouraged for routine use (there be dragons here)
12:40:48.367 It is strongly recommended to provide a known_list, and use it as a whitelist (device_id filter), configure: enforce_known_list = True
12:40:48.536 Not using any device filter: using a known_list (as a whitelist) is strongly recommended)
12:40:51.589 The cmd timed out, cancelling the task (RQ --- 18:000730 01:244016 --:------ 1F09 001 00)
12:41:33.666 PktProtocolQos.send_data(sent=7FFF| I|63:262142): boff=3, want=7FFF| I|63:262142, tout=2022-06-10T12:41:33.661: QoS: IS_EXPIRED (giving up) (24/24)
12:41:41.677 PktProtocolQos.send_data(sent=1F09|RQ|01:244016): boff=3, want=1F09|RQ|01:244016, tout=2022-06-10T12:41:41.674: QoS: IS_EXPIRED (giving up) (3/3)
12:41:41.677 PktProtocolQos.send_data(1F09|RQ|01:244016): Expired callback
I made a little program, to try to understand, and I noticed that the communication stops after trying to write on one of the devices, as long as I listen it works, after I tried to write it stops and I don’t listen to anything anymore
import serial
ser = serial.Serial('/dev/ttyUSB0', 115200, timeout=0.050)
count = 0
ser.write(str.encode("!F\n\r"))
#18:056026
#18:000730
while 1:
if (count==250 or count==280 or count==300):
invio = str.encode(" W --- 18:000730 04:030562 --:------ 2349 007 00086600FFFFFF\r\n")
ser.write(bytes(invio))
print(bytes(invio))
data = ser.readline().decode("ascii")
if (data!=""):
print(data)
count +=1
And reply work, until I write
# evofw3 0.7.1
055 I --- 01:244016 --:------ 01:244016 2349 007 01070800FFFFFF
055 I --- 01:244016 --:------ 01:244016 2309 003 010708
b' W --- 18:056026 04:030562 --:------ 2349 007 00086600FFFFFF\r\n'
b' W --- 18:056026 04:030562 --:------ 2349 007 00086600FFFFFF\r\n'
b' W --- 18:056026 04:030562 --:------ 2349 007 00086600FFFFFF\r\n'
Maybe that’s why your program doesn’t read me, because at the beginning it already sends a broadcast command.
But I didn’t understand why it has this strange behavior, my evofw3 release is 0.7.1
Thanks again
Try this:
python client.py -ge listen /dev/ttyUSB0
… and this:
python client.py -ge listen alt:///dev/ttyUSB0?class=PosixPollSerial
I would re-install evofw3.
Something begins to show, with an error
client.py: Starting ramses_rf...
16:14:38.031 enable_eavesdrop enabled: this is discouraged for routine use (there be dragons here)
16:14:38.033 It is strongly recommended to provide a known_list, and use it as a whitelist (device_id filter), configure: enforce_known_list = True
16:14:38.930 Not using any device filter: using a known_list (as a whitelist) is strongly recommended)
16:15:10.393 I --- 04:030562 --:------ 01:244016 3150 002 0000 < AttributeError('NoneType' object has no attribute 'reap_htg_zone')
16:15:10.394 I --- 04:030562 --:------ 01:244016 3150 002 0000 < exception from app layer: 'NoneType' object has no attribute 'reap_htg_zone'
Traceback (most recent call last):
File "/home/sistemi/PycharmProjects/ramses_rf/ramses_rf/protocol/protocol.py", line 201, in _pkt_receiver
p.data_received(msg)
File "/home/sistemi/PycharmProjects/ramses_rf/ramses_rf/protocol/protocol.py", line 483, in data_received
self._callback(self._this_msg, prev_msg=self._prev_msg)
File "/home/sistemi/PycharmProjects/ramses_rf/ramses_rf/message.py", line 348, in process_msg
msg.src._handle_msg(msg)
File "/home/sistemi/PycharmProjects/ramses_rf/ramses_rf/devices_heat.py", line 1425, in _handle_msg
super()._handle_msg(msg)
File "/home/sistemi/PycharmProjects/ramses_rf/ramses_rf/devices_base.py", line 735, in _handle_msg
self._set_parent(self.ctl.tcs.reap_htg_zone(msg.payload[SZ_ZONE_IDX]))
AttributeError: 'NoneType' object has no attribute 'reap_htg_zone'
16:15:10.391 || TRV:030562 | CTL:244016 | I | heat_demand | 00 || {'zone_idx': '00', 'heat_demand': 0.0}
16:15:49.561 || CTL:244016 | | I | system_sync | || {'remaining_seconds': 226.0, '_next_sync': '16:19:35'}
16:15:49.575 || CTL:244016 | | I | setpoint | [..] || [{'zone_idx': '00', 'setpoint': 12.0}, {'zone_idx': '01', 'setpoint': 18.0}]
16:15:49.587 || CTL:244016 | | I | temperature | [..] || [{'zone_idx': '00', 'temperature': 25.39}, {'zone_idx': '01', 'temperature': 25.5}]
With this there are no mistakes
client.py: Starting ramses_rf...
16:18:46.853 enable_eavesdrop enabled: this is discouraged for routine use (there be dragons here)
16:18:46.853 It is strongly recommended to provide a known_list, and use it as a whitelist (device_id filter), configure: enforce_known_list = True
16:18:46.985 Not using any device filter: using a known_list (as a whitelist) is strongly recommended)
16:19:35.559 || CTL:244016 | | I | system_sync | || {'remaining_seconds': 226.0, '_next_sync': '16:23:21'}
16:19:35.571 || CTL:244016 | | I | setpoint | [..] || [{'zone_idx': '00', 'setpoint': 12.0}, {'zone_idx': '01', 'setpoint': 18.0}]
16:19:35.586 || CTL:244016 | | I | temperature | [..] || [{'zone_idx': '00', 'temperature': 25.39}, {'zone_idx': '01', 'temperature': 25.5}]
16:19:37.079 || TRV:030562 | CTL:244016 | I | setpoint | 00 || {'zone_idx': '00', 'setpoint': 15.0}
16:19:37.102 || CTL:244016 | | I | zone_mode | 00 || {'zone_idx': '00', 'mode': 'temporary_override', 'setpoint': 15.0, 'until': '2022-06-10T17:00:00'}
16:19:37.109 || CTL:244016 | | I | setpoint | 00 || {'zone_idx': '00', 'setpoint': 15.0}
16:19:44.475 || TRV:030562 | CTL:244016 | I | setpoint | 00 || {'zone_idx': '00', 'setpoint': 15.0}
16:20:09.450 || CTL:244016 | | I | zone_mode | 00 || {'zone_idx': '00', 'mode': 'follow_schedule', 'setpoint': 12.0}
16:20:09.459 || CTL:244016 | | I | setpoint | 00 || {'zone_idx': '00', 'setpoint': 12.0}
16:20:18.276 || TRV:030560 | CTL:244016 | I | heat_demand | 01 || {'zone_idx': '01', 'heat_demand': 0.0}
Actually I have already reloaded the firmware, and everything seems to be ok when loading
But is correct to send this byte array for write setpoint?
str.encode(" W --- 18:000730 04:030562 --:------ 2349 007 00086600FFFFFF\r\n")
Could it be the address 18:000730 that doesn’t make it work in writing ? I also tried with 18:056026, but it’s the same thing
Since my evohome kit is quite recent, I wouldn’t want them to dislike the nanoCul address
You tell the controller the new setpoint for a zone, not the TRV - during the next sync_cycle, the TRVs will get that info via the 2309 array that the controller periodically sends.
from ramses_rf.protocol.command import Command
gwy.send_cmd(
Command.set_zone_setpoint(gwy.tcs.id, 0, 19.9)
) # set target temp for zone 0 to 19.9C
If required, simply do this:
print(Command.set_zone_setpoint("01:244016", 0, 19.9))
This is the array that the controller periodically sends:
15:07:57.995 -> 031 I --- 01:244016 --:------ 01:244016 1F09 003 FF08D4
15:07:58.065 -> 031 I --- 01:244016 --:------ 01:244016 2309 006 0004B0-010708
15:07:58.065 -> 031 I --- 01:244016 --:------ 01:244016 30C9 006 000AC6-010AF7
… I have added the dashes, so you can see zone 0 (“00”) and zone 1 (“00”).
Ah ok, it always goes through the controller. My final plan was to remove the controller, but at this point I think that’s not possible
ramses_rf could be used to do this - you would create a faked controller and bind the TRVs to it (or have the faked controller simply use the same device ID). There would be some coding involved.
I have started doing the above - the code is very alpha…
But why would you want to? I can’t really think of a viable use-case.