I’m never seeing anything from the dispatcher in the logs using this.
logger:
default: warn
logs:
homeassistant.core: warn
custom_components.ramses_cc: info
ramses_rf.dispatcher: info
ramses_rf.protocol.protocol: info
ramses_rf.protocol.transport: info
What could I be doing wrong?
hi all
I recently upgraded HA to 2023.2.3 and ramses_cc broke. I’ve got ramses_cc install via HACS, version 0.22.3.
I’ve read the ramses_cc release notes about bugs relating to CELCIUS, and have exactly that error message in my log. so my conclusion is that I need to upgrade it. But there I get stuck. there’s no upgrade button in the ramses_cc integration in the HA front end.
There’s no “how to upgrade” in the ramses_cc wiki either (if there is, please feel free to point it out to me).
So , basic question: how do I upgrade my ramses_cc to the latest version, and can it be done without losing all the config that I have for the various climate entities?
if this needs to be done “under the hood” with CLI, it would be very much appreciated if someone can spell out exactly what is needed.
ta
Ian
Hello,
if you have installed ramses_cc via HACS, you should see the new version in HACS and you can update from there.
I am not sure what you call losing all the config that you have for the various entities but updating does not impact your configuration.yaml so you do not loose the configuration. The data in the entities is also maintained as far as I remember (i.e. history of temperature, …).
I did install ramses_cc from HACS. When I go into HACS->Integrations, there is no new version appearing for ramses_cc. see screenshots,
If there was an upgrade button (like appears on the other HACS integrations), I would have just pressed it and wouldn’t be asking this question.
I do have other HACS custom Integrations installed, and their upgrade buttons appear and work just fine.
what I meant by “losing config” is that I have a bunch of dashboards and a couple of automations that use the climate entities for the rooms, and the long form numeric sensor ID’s as well, that were painstaking to get configured. (many thanks to those who posted their dashboards into the wiki for this component, I copied ideas from several) .If all the entities were to disappear and all those to have to to be reconfigured, that’d be a pain.
if its not going to wipe config I’d be happy to delete ramses_cc and re-install, but I can’t even see how to do that. sorry if this is basic to some but its not obvious.
thanks
well I solved my own problem. posting answer here to help others.
for whatever reason the Blue “update” button doesn’t pop up for ramses_cc within HACS. Solution is to click into Ramses_cc in HACS, then go to top right hand corner and select “Redownload”. then set the option for “show beta versions” and 22.4 appears, at which point download it and restart.
22.4 fixed my issue.
@zxdavb I have sent a PM with my log files.
I restarted HA just after midnight yesterday morning as requested.
Our UFH controller is an HCC80R.
The system has three UFH zones, the first of which includes two circuits.
The zones heat correctly, but the Evohome System Status shows UFH heat demand on only the first zone, regardless of which zone is actually active.
PS. As a bonus, the logs include a boiler service between 8am and 9am yesterday! 
Although I may not have the time to expose per-circuit heat demand in the shorter term, this is the time when UFH is being active, so we need to collect this data now…
Can anyone else who has UFH provide packets logs? They will need to include a restart of HA, and last for > 24 hours (say two days).
Almost all of the existing logs I have (those I have collected over the last few years) do not contain the information I need.
An HR92 went to 101% open this morning and generated this in the log file. I’ll force it to recalibrate, but thought I’d report the error anyway.
evohome_0.21.40 homeassistant_2023.1.7
Logger: ramses_rf.protocol.message
Source: /usr/local/lib/python3.10/site-packages/ramses_rf/protocol/message.py:358
First occurred: 08:30:17 (4 occurrences)
Last logged: 09:30:17
I --- 04:133367 --:------ 01:196480 3150 002 00CA < Coding error: ValueError(Invalid result: 1.01 (0xCA) is > 1)
Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/message.py", line 331, in _validate
result = PAYLOAD_PARSERS.get(self.code, parser_unknown)(
File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/parsers.py", line 140, in wrapper
result = fnc(payload, msg, **kwargs)
File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/parsers.py", line 2040, in parser_3150
return valve_demand(payload[2:]) # TODO: check UFC/FC is == CTL/FC
File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/helpers.py", line 23, in wrapper
return fnc(*args, **kwargs)
File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/helpers.py", line 318, in valve_demand
raise ValueError(f"Invalid result: {result} (0x{value}) is > 1")
ValueError: Invalid result: 1.01 (0xCA) is > 1
I have see this before… It is a puzzle to me why it gets to 101%, so I’ve not bothered to prevent the ValueError.
You can ignore this message.
I know it not causing me a real problem, but would that explain why some mornings in HA that actuator has reported a position of 0% when all others have shown they have opened to 100%, then that one particular actuator has then indicated a position as it starts to close?
Not exactly.
Since the 101% packet isn’t processed, the actuator will continue to report it’s last %open, as long as it has a previous packet that has not expired.
The last %open could have been 0%, but could any value 0-100% (or 0.0 to 1.0).
If the packet has expired, then the value will be None.
Just search your packet log for 04:133367 --:------ 01:196480 3150 packets and see what payload was before the 00CA.
Just convert the 0xCA (hex) to decimal and divide by 100.
Hi.
Yes, I can see it. This morning the actuator was at 0%, but as you say it could be another value if the temperature had dropped enough overnight. At 8.30 the schedule increases the setpoint for that zone.
2023-02-12T07:05:23.619465 050 I --- 04:133367 --:------ 01:196480 3150 002 0000 # 0%
2023-02-12T07:25:23.266373 050 I --- 04:133367 --:------ 01:196480 3150 002 0000 # 0%
2023-02-12T07:45:25.454516 050 I --- 04:133367 --:------ 01:196480 3150 002 0000 # 0%
2023-02-12T08:05:24.389512 050 I --- 04:133367 --:------ 01:196480 3150 002 0000 # 0%
2023-02-12T08:25:23.835755 050 I --- 04:133367 --:------ 01:196480 3150 002 0000 # 0%
2023-02-12T08:30:17.093217 050 I --- 04:133367 --:------ 01:196480 3150 002 00CA # 101% # at 08:30am zone setpoint change from 14C to 18C
2023-02-12T08:50:14.104401 050 I --- 04:133367 --:------ 01:196480 3150 002 00CA # 101%
2023-02-12T09:10:13.246284 050 I --- 04:133367 --:------ 01:196480 3150 002 00CA # 101%
2023-02-12T09:30:17.669887 050 I --- 04:133367 --:------ 01:196480 3150 002 00CA # 101%
2023-02-12T09:40:58.728457 050 I --- 04:133367 --:------ 01:196480 3150 002 00AC # 86%
Yes, so what you’re seeing is the actuator reporting 0%, when it should really be 100%. Not ideal.
Its zone may also report incorrectly, depending on what other actuators are involved.
I guess I need to do something about it…
Cheers, its
Cheers, it’s appreciated:-)
In your packet logs, there are no packets from the UFH controller (UFC) to the USB dongle (HGI).
This is usually due to an issue with reception - it appears the UFC can’t ‘hear’ the HGI - perhaps you could try tuning it (assuming it is an evofw3 FW).
Hey,
trying to send a remote command to my vasco house ventilation system and it is failing or at least nothing happens plus see this unknown mode_set: 06
I see the entities and values are ok. using nanoCul and flashing went well.
this is my config
ramses_cc:
serial_port: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0
packet_log:
file_name: packet.log
rotate_backups: 28
ramses_rf:
enforce_known_list: false # if not true, still enforces the block_list
disable_discovery: false
disable_sending: false # do not transmit any packets, ever
enable_eavesdrop: true # can be used to create an initial system schema
known_list:
04:136151: # HR92 office
04:136125: # HR92 garage
04:135705: # HR92 gang
18:262143: # nanoCul 868 Mhz dongle
class: HGI
_note: nanoCul 868 Mhz
29:079817: # vasco fan
class: FAN
30:006056: # honeywell gateway
class: REM
faked: true
commands:
auto: " I --- 30:006056 29:079817 --:------ 22F1 003 000506"
low: " I --- 30:006056 29:079817 --:------ 22F1 003 000206"
medium: " I --- 30:006056 29:079817 --:------ 22F1 003 000306"
high: " I --- 30:006056 29:079817 --:------ 22F1 003 000406"
29:136571: # remote beneden co2 sensor plus remote
29:087720: # remote boven
class: REM
faked: true
commands:
auto: " I --- 29:087720 29:079817 --:------ 22F1 003 000506"
low: " I --- 29:087720 29:079817 --:------ 22F1 003 000206"
medium: " I --- 29:087720 29:079817 --:------ 22F1 003 000306"
high: " I --- 29:087720 29:079817 --:------ 22F1 003 000406"
this works from the app or remote
Auto
2023-02-18T19:22:41.771673 031 I --- 30:006056 29:079817 --:------ 22F1 003 000506
Hard
2023-02-18T19:21:40.568270 031 I --- 30:006056 29:079817 --:------ 22F1 003 000406
middle
2023-02-18T19:25:45.197074 032 I --- 30:006056 29:079817 --:------ 22F1 003 000306
low
2023-02-18T19:26:45.342386 031 I --- 30:006056 29:079817 --:------ 22F1 003 000206
when I try to do this I get this error and nothing happens
2023-02-18T21:28:02.860566 000 I --- 29:087720 29:079817 --:------ 22F1 003 000406
I see this error
2023-02-18 21:28:02.164 INFO (MainThread) [ramses_rf.protocol.protocol] SENT: I --- 29:087720 29:079817 --:------ 22F1 003 000406
2023-02-18 21:28:02.164 INFO (MainThread) [ramses_rf.protocol.transport] Impersonating device: 29:087720, for pkt: 22F1| I|29:087720
2023-02-18 21:28:02.165 INFO (MainThread) [ramses_rf.protocol.transport] RF Tx: b' I --- 18:000730 63:262142 --:------ 7FFF 023 00110186663654F432324631204932393A303837373230'
2023-02-18 21:28:02.217 INFO (MainThread) [ramses_rf.protocol.transport] RF Rx: b'000 I --- 18:262143 63:262142 --:------ 7FFF 023 00110186663654F432324631204932393A303837373230'
2023-02-18 21:28:02.219 INFO (MainThread) [ramses_rf.protocol.protocol] rcvd: I --- 18:262143 63:262142 --:------ 7FFF 023 00110186663654F432324631204932393A303837373230
2023-02-18 21:28:02.421 INFO (MainThread) [ramses_rf.protocol.transport] RF Tx: b' I --- 18:000730 63:262142 --:------ 7FFF 023 00110186663654F432324631204932393A303837373230'
2023-02-18 21:28:02.474 INFO (MainThread) [ramses_rf.protocol.transport] RF Rx: b'000 I --- 18:262143 63:262142 --:------ 7FFF 023 00110186663654F432324631204932393A303837373230'
2023-02-18 21:28:02.475 INFO (MainThread) [ramses_rf.protocol.protocol] rcvd: I --- 18:262143 63:262142 --:------ 7FFF 023 00110186663654F432324631204932393A303837373230
2023-02-18 21:28:02.626 INFO (MainThread) [ramses_rf.protocol.transport] RF Tx: b' I --- 18:000730 63:262142 --:------ 7FFF 023 00110186663654F432324631204932393A303837373230'
2023-02-18 21:28:02.678 INFO (MainThread) [ramses_rf.protocol.transport] RF Rx: b'000 I --- 18:262143 63:262142 --:------ 7FFF 023 00110186663654F432324631204932393A303837373230'
2023-02-18 21:28:02.680 INFO (MainThread) [ramses_rf.protocol.protocol] rcvd: I --- 18:262143 63:262142 --:------ 7FFF 023 00110186663654F432324631204932393A303837373230
2023-02-18 21:28:02.830 INFO (MainThread) [ramses_rf.protocol.transport] RF Tx: b' I --- 29:087720 29:079817 --:------ 22F1 003 000406'
2023-02-18 21:28:02.860 INFO (MainThread) [ramses_rf.protocol.transport] RF Rx: b'000 I --- 29:087720 29:079817 --:------ 22F1 003 000406'
2023-02-18 21:28:02.861 INFO (MainThread) [ramses_rf.protocol.protocol] rcvd: I --- 29:087720 29:079817 --:------ 22F1 003 000406
2023-02-18 21:28:02.862 WARNING (MainThread) [ramses_rf.protocol.parsers] I --- 29:087720 29:079817 --:------ 22F1 003 000406 < Support the development of ramses_rf by reporting this packet (unknown mode_set: 06)
doing it again from the device
2023-02-18T21:55:59.652228 032 I --- 30:006056 29:079817 --:------ 22F1 003 000206
2023-02-18T21:55:59.860881 031 I --- 30:006056 29:079817 --:------ 22F1 003 000206
2023-02-18T21:55:59.889166 071 I --- 29:079817 --:------ 29:079817 31D9 003 000002
2023-02-18T21:56:00.068106 032 I --- 30:006056 29:079817 --:------ 22F1 003 000206
2023-02-18T21:56:00.136455 072 I --- 29:079817 --:------ 29:079817 31D9 003 000002
2023-02-18 21:55:59.651 INFO (MainThread) [ramses_rf.protocol.transport] RF Rx: b'032 I --- 30:006056 29:079817 --:------ 22F1 003 000206'
2023-02-18 21:55:59.653 INFO (MainThread) [ramses_rf.protocol.protocol] rcvd: I --- 30:006056 29:079817 --:------ 22F1 003 000206
2023-02-18 21:55:59.654 WARNING (MainThread) [ramses_rf.protocol.parsers] I --- 30:006056 29:079817 --:------ 22F1 003 000206 < Support the development of ramses_rf by reporting this packet (unknown mode_set: 06)
2023-02-18 21:55:59.860 INFO (MainThread) [ramses_rf.protocol.transport] RF Rx: b'031 I --- 30:006056 29:079817 --:------ 22F1 003 000206'
2023-02-18 21:55:59.861 INFO (MainThread) [ramses_rf.protocol.protocol] rcvd: I --- 30:006056 29:079817 --:------ 22F1 003 000206
2023-02-18 21:55:59.862 WARNING (MainThread) [ramses_rf.protocol.parsers] I --- 30:006056 29:079817 --:------ 22F1 003 000206 < Support the development of ramses_rf by reporting this packet (unknown mode_set: 06)
2023-02-18 21:55:59.888 INFO (MainThread) [ramses_rf.protocol.transport] RF Rx: b'071 I --- 29:079817 --:------ 29:079817 31D9 003 000002'
2023-02-18 21:55:59.889 INFO (MainThread) [ramses_rf.protocol.protocol] rcvd: I --- 29:079817 --:------ 29:079817 31D9 003 000002
2023-02-18 21:56:00.067 INFO (MainThread) [ramses_rf.protocol.transport] RF Rx: b'032 I --- 30:006056 29:079817 --:------ 22F1 003 000206'
2023-02-18 21:56:00.068 INFO (MainThread) [ramses_rf.protocol.protocol] rcvd: I --- 30:006056 29:079817 --:------ 22F1 003 000206
2023-02-18 21:56:00.068 WARNING (MainThread) [ramses_rf.protocol.parsers] I --- 30:006056 29:079817 --:------ 22F1 003 000206 < Support the development of ramses_rf by reporting this packet (unknown mode_set: 06)
2023-02-18 21:56:00.135 INFO (MainThread) [ramses_rf.protocol.transport] RF Rx: b'072 I --- 29:079817 --:------ 29:079817 31D9 003 000002'
2023-02-18 21:56:00.136 INFO (MainThread) [ramses_rf.protocol.protocol] rcvd: I --- 29:079817 --:------ 29:079817 31D9 003 000002
I think I am doing something wrong by impersonating a remote device.
thanks
This may be worth reading by all, even though I am responding to @biemond’s question.
Tip: The CH/DHW domains are completely separate - they never talk to each other.
Without looking at a packet log, I cannot be 100% certain you have the correct classes - in any case, this is certainly not a Honeywell RFG100 gateway and a HVAC remote.
For the CH/DHW devices, you can always determine its class (e.g. controller, TRV, relay) by its device address prefix:
01:123456: controller02:123456: UFH controller30:123456: internet gatewayBut for the HVAC domain, they do what that like, including using the CH/DHW prefixes:
02:123456: could be a remote30:123456: could be a FAN (e.g. extractor, PIV or HRU)If you’re not sure, then enabling eavesdropping may be able to determine the device class for you.
Support the development of ramses_rf by reporting this packet (unknown mode_set: 06)
This message is because ramses_rf has seen a packet (format) that it has never seen before. This is uncommon, but can happen as more & more people use ramses_cc.
The idea would be to let me know, and I can do what ever is required:
If it is not one of the above, then it is either:
NOTE: even with poorly-constructed command packets, they are still transmitted
Below we have an example of such a packet (a frame, really) - it is still transmitted (as long as it is in a valid format), and so
That is, frames are only processed when they are received, not when they are transmitted.
We can see this below.
ANyway, if the FAN is not changing it’s behaviour as this packet is transmitted (and we can assume it was also received), then the packet is not ‘right’ from the receiving devices point of view (and possibly also why ramses_rf is throwing a warning), for example:
In short - you raise interesting issues (why I’ve provided a lengthy answer), but your question is an XY problem.
And it is difficult to answer, as I have no way of knowing that your schema is correct…
So, if you want a more specific answer - then provide a 24h packet log, which includes a restart of HA, along with a description of what you’re trying to do (rather than how you’re trying to achieve what you’re trying to do). Include a description of your kit. PM me me if you like.
Thanks for the great work and this reply, it is awesome you put some much time in in this and try to help us all. very appreciated. I will DM you with the output.
To give you some context.
In NL probably everywhere with the new building insulation rules we have to control the air flow and refresh. So I have some vasco system. (NL or EU player)
With this I can measure/control the airflow in my house plus some have some heating zones to close raditor valves in some of the rooms. Some also have thermostat with floor heating control but my heating is done with google nest and central heating boiler is controlled with opentherm, this is out of scope and not on RF , (directly connected).
Until now I have entities with good values for my hr92 temp, co2 sensor and fan speeds. Indeed was looking at the classes and try to use the ones which makes most sense to me.
So my goal is to get all the values plus control the FAN and maybe set the zones heating from HA. Was trying to use to 30:006056, 29:136571 as remote. it looks like indeed → source/destination address set is not valid/correct
My setup
18:262143: # nanoCul 868 Mhz dongle
Sorry for the dutch links, seems some rebranded honeywell products are not sold outside NL.
rebranded honeywell hr92, this vasco.eu/nl/climate-control/rf-thermostaatknop
04:136151 hr92 office
04:136125 hr92 garage
04:135705 hr92 gang
29:079817 FAN on the attic, this C400RF - Vasco
2023-02-18 19:16:26.835 INFO (MainThread) [custom_components.ramses_cc.climate_hvac] Found a HVAC system: 29:079817 (FAN)
30:006056 honeywell/ vasco internet gateway is indeed an internet gateway see Gateway Climate Control voor ventilatie - Vasco
with this I can control 3 zone for my radiotors and make a fan schedule or floor heating
29:136571 remote downstairs with co2 see vasco.eu/nl/ventilatie/rf-co2-schakelaar
29:087720 remote upstairs/bathroom see vasco.eu/nl/ventilatie/rf-3-standenschakelaar
Will send you a DM with the 24 hours logs and do all the restarts
hope my setup make sense to you
thanks again.
