I’m having an issue getting my zone names through to HA. In my yaml config I have the following:
zones:
'00':
_name: Office
zone_type: radiator_valve
sensor: '04:041296'
actuators:
- '04:041296'
Which keeps passing trough to HA with a null value for _name:
schema:
_name: null
class: radiator_valve
sensor: '04:041296'
actuators:
- '04:041296'
I’ve tried wrapping the text in quotes and it doesn’t seems to make a difference. Any suggestions?
This yaml key starts with an underscore. These keys are ‘special’ to ramses_rf - it is included in the ‘output’ (i.e. from HA to you) schema only for convenience.
Actually, the zone name is not part of the schema; it is considered to be a configuration parameter, similar to (say) the zone’s setpoint or operating mode. That is, you can change the zone’s name without destroying / re-creating the zone.
That is, there is:
schema: e.g. which sensor / TRV in which zone, which BDR is doing whatparams: e.g. zone name / setpoint, DHW parameters, system modestatus: e.g. zone temperature, DHW temperature, relay open/closedI fear you may have been misinformed…
Please keep your hand-crafted / configured (‘input’) schema to the absolute minimum you can get away with. For most people that would be just the controller id, or (if you have one) the controller plus the OTB bridge.
Other exceptions include the older TRVs (HR80s), or very rare edge cases (HM80s, corrupt device IDs, etc)…
A minimal configured (‘input’) schema is all that is necessary: the internal / working (‘real’) schema is determined by discovery shortly after start up of HA, and the working schema is periodically cached in a permanent store - that cached schema is then used during subsequent startups of HA, and it will overrule your configured schema.
(actually, for technical reasons, ramses_rf will have a go at merging the two - if it is unsuccessful at doing so, it will simply ignore the configured schema).
Is this an x-y problem? That is, do your zone names show up in HA, or not?
In either case, just use the smallest schema you can get away with, as above, and let us know how you get on.
Also let us know if this is not clearly described in the wiki.
I am inclined to say no at this stage - I am not sure if the effort required to integrate it/maintain it would benefit a sufficient % of the user base - and I know Pete (who maintains evofw3) is working on a similar solution…
And ramses_cc exposes events and service calls that can be leveraged for such needs as yours…
As an aside, I have completely re-written the protocol layer of ramses_rf…
It is now stateful (you can send a packet, and wait for the response) - this will make things much easier, going forward.
I am looking for someone to take on ramses_cc, whilst I focus on ramses_rf - you will need python coding experience and know the HA APIs well… let me know if that is you.
Thanks for the response - I wouldn’t for as far as misinformed, more like misassumed! Definitely a PICNIC.
Two zones weren’t attributing actuators correctly initially, so I decided to include the whole schema. In reality I can strip it back to just those two zones & let the rest auto generate.
When this happens - it is almost always because the bindings (between the controller and the TRVs) are not at you think they are.
Overruling what ramses_rf believes to be true via a hand-crafted schema won’t change the reality of this.
Please post your ramses_cc: section here, and I’ll comment on it for you.
Or - better still - PM me your entire cache (in config/.storage/ramses_cc).
Kindly ask for support with controlling Vasco D500 ventilation unit with RF (4 buttons) remote.
I successfully configured ramses_cc with faking. I see packets from original RF transmitter:
> 058 I --- 29:083043 32:024669 --:------ 22F1 003 000206
> 060 I --- 29:083043 32:024669 --:------ 22F1 003 000306
> 060 I --- 29:083043 32:024669 --:------ 22F1 003 000406
in configuration.yaml i got faking device:
known_list:
18:070952: {class: HGI}
29:083043: {class: REM, faked: true}
32:024669: {class: FAN, _note: D500}
29:073042:
class: REM
faked: True
commands:
low: ' I --- 29:073042 32:024669 --:------ 22F1 003 000206'
medium: ' I --- 29:073042 32:024669 --:------ 22F1 003 000306'
max: ' I --- 29:073042 32:024669 --:------ 22F1 003 000406'
and using the command:
service: remote.send_command
data:
command: max
target:
entity_id: remote.29_083043
i see packet beeing transmited that exactly match that what were sniffed:
000 I --- 29:083043 32:024669 --:------ 22F1 003 000406
but ventilation unit is not reacting on any command.
Could you please support, and advice what would be the potential root cause, and how it can be improved ?
I also received this information in logs:
Thanks!
I’ve checked my bindings & indeed they are correct - however 1 zone shows 2 actuators, where there is in fact 3 (& confirmed this on the heads). How do I force a refresh of the schema? I’ve tried:
ramses_cc:
restore_state: false
& it returns an error in the yaml.
Please look at this from my point of view - there is only one of me, and hundreds? of people using this integration… This is not the only channel where people ask for help.
I am time-poor.
I advised you to do something so that I could help you, and instead of doing so you’ve challenged my conclusion about your bindings without offering adequate evidence that I’m incorrect…
That is, how did you confirm your bindings? Did you ask the controller (if so, how?), or did you simply ask the TRVs? As I said, the issue is what the controller believes to be true.
Perhaps, to be sure, you’ve simply re-bound the TRVs to the controller (a reasonable black-box strategy). You haven’t said.
I don’t have time to justify my thinking further…
Please make more of an effort, and place less of the burden of your troubleshooting upon me…
For example:
… perhaps you could have have posted the actual error message? That would save me the time having to ask you for it, or try to work out the issue in the absence of that information.
FWIW, have a look at the wiki, and you’ll see the answer to your question.
If you want any more help from me, PM me your current .storage/ramses_cc file.
I understand you’re using both 29:083043 (an impersonated physical switch/remote - the ‘original’) and 29:073042 (a fully faked virtual REM, correct?).
And these are the actual command packets as sniffed, from the physical device:
058 I --- 29:083043 32:024669 --:------ 22F1 003 000206
… and you’ve never seen a 3-digit number after the I, like so:
058 I 123 29:083043 32:024669 --:------ 22F1 003 000206
My observation:
29:083043 is bound (it works), but that 29:073043 is not?My suggestion:
commands: section to the real remote, and use that (this will be OK if the switch is stateless - most are)Let me know how that goes…
This is a warning that you can ignore for now.
@zxdavb - Thanks for you kind reply.
I had modified acc. to your advise and see that identical packet is beeing trasmited as from phisical remote, but without reaction and reply from the unit. It seems like transmitting issue - i will try today with different setup (new nano and radio), and give the feedback.
Modified config:
32:024669: {class: FAN, _note: D500}
29:083043:
class: REM
faked: True
commands:
low: ' I --- 29:083043 32:024669 --:------ 22F1 003 000206'
medium: ' I --- 29:083043 32:024669 --:------ 22F1 003 000306'
max: ' I --- 29:083043 32:024669 --:------ 22F1 003 000406'
where 29:083043 is the physical remote binded to the unit.
Blockquote
… and you’ve never seen a 3-digit number after theI, like so:
058 I 123 29:083043 32:024669 --:------ 22F1 003 000206
indeed. There is always “—”, no numbers.
Thanks,
Maciej
ramses-rf is receiving the packet of the sent command as echoed by the USB dongle. So, one of two things this happened here…
So: have you evidence that any RF device has ever heard the dongle?
The way I would normally confirm this is by having a second USB dongle listening…
I warn you that if you load the evofw3 firmware onto the USB dongle incorrectly (e.g. wrong boot loader), or if the nano hardware is dodgy, then option is likely…
Both scenarios are quite common.
Hi David,
unfortunetlly it seems like transmitting issue.
I had setuped two devices (nano + CC1101) they can listen to the traffic, but transmit fails on both.
Could you please advise me, what i did wrongly?
Firmware is loaded without any issue, bootloaders are updated by ArduinoISP. Wiring as follow:
config.h
[...]
#define ARDUINO_EVOFW3_ATMEGA328P
#define SPI_CLK_RATE 250000
#define HOST_RATE 115200
[...]
atm328_pins.h
[...]
// SPI port defs
#define SPI_PORT PORTB
#define SPI_PIN PINB
#define SPI_DDR DDRB
#define SPI_SS CCSEL
#define SPI_MOSI 3
#define SPI_MISO 4
#define SPI_SCLK 5
[...]
on transmitter i see:
type or paste code here
Kindly appreciate your support!
— Update 21:57
OK @zxdavb - i migrated with radio to 32u4 and sucessully managed to transmit data.
Using setup i transmit identical packet as the original RF remote, but unit is likely ignore this data and does not reply with 31D9.
Can you please advise what is the root cause?
also before sending fake packet i see some unknown packets:
076 I --- 18:201223 63:262142 --:------ 7FFF 023 00110189B8B1482C32324631204932393A30383330343
077 I --- 18:201223 63:262142 --:------ 7FFF 023 00110189B8B1482C32324631204932393A30383330343
076 I --- 18:201223 63:262142 --:------ 7FFF 023 00110189B8B1482C32324631204932393A30383330343
076 I --- 29:083043 32:024669 --:------ 22F1 003 000206
@sciorty i also followed you advise and ordered SSM-D2. Will let you all know if this solved the issue also in my case.
btw @zxdavb is there any way to disable sending RQ packets, as they seems useless in my case (VASCO is omitting them) ?
Also it seems like VASCO uses 3 way handshake for pairing new devices. Is it already implemented function? Can i bind faked device to the unit?
Pairing the RF:
067 I --- 29:083043 63:262142 --:------ 1FC9 024 0022F17544630022F37544636610E0754463001FC9754463
079 W --- 32:024669 29:083043 --:------ 1FC9 012 0031D980605D0031DA80605D
066 I --- 29:083043 32:024669 --:------ 1FC9 001 00
— Update
short update as i see this a blocking point:
the packets trasmited from original RF works fine and looks like this:
I --- 29:083043 32:024669 --:------ 22F1 003 000206 < Support the development of ramses_rf by reporting this packet (unknown mode_set: 06)
2023-08-03 02:14:39 |073| 29:083043 -> 32:024669 | I| fan_mode | medium
2023-08-03 02:14:39,311 [311] ----> Unknown zone for src: '29:083043 (HVC) '
packets from faked device not working, but seems identical - they are preceded with some gateway packets that i do not understand.
2023-08-03 02:13:34 |074| HGI evoGateway -> NUL UNBOUND | I| puzzle_packet | datetime: 2023-08-03T02:13:34.145, impersonating: 22F1| I|29:083043, parser: v0.22.40
2023-08-03 02:13:34 |075| HGI evoGateway -> NUL UNBOUND | I| puzzle_packet | datetime: 2023-08-03T02:13:34.145, impersonating: 22F1| I|29:083043, parser: v0.22.40
2023-08-03 02:13:34 |074| HGI evoGateway -> NUL UNBOUND | I| puzzle_packet | datetime: 2023-08-03T02:13:34.145, impersonating: 22F1| I|29:083043, parser: v0.22.40
I --- 29:083043 32:024669 --:------ 22F1 003 000206 < Support the development of ramses_rf by reporting this packet (unknown mode_set: 06)
2023-08-03 02:13:34 |076| 29:083043 -> 32:024669 | I| fan_mode | medium
any advise, what could be the root cause?
Steve, you have sent me a packet log, which is not what I had asked for… Nonetheless, in this instance, the packet log has the answer you need (it just may not have the whole answer).
First, can I ask: have you not seen errors similar to these in your error log:
CorruptStateError: schema is inconsistent: 04:041292 (TRV): cant change parent (01:220768_01 to 01:220768_05 (try restarting the client library)
If you have not - then you should have - I’ll have to work out why - let me know.
In short, what the above says is that:
04:041292 was bound to a zone (zone_idx = 0x01), then without destroying that zone,NOTE: It is a common misconception that controllers will remove a TRV from its old zone when it is bound to a new zone - this is incorrect.
In this case, the TRV will tell you it is bound to zone 5, but the controller thinks it is bound to both zones, and send a packet to ramses_rf saying so. Rightfully, ramses_rf won’t accept that - the packet is not processed, and any other data is that packet is ignored.
In detail (using data from your packet log):
The gateway asks (RQ, request) the controller for the actuators of zone 0x01, and gets the following response (RP):
RQ --- 18:137484 01:220768 --:------ 000C 002 0100
RP --- 01:220768 18:137484 --:------ 000C 018 01000010A14A01000010A15601000010A14C
This translates to:
RQ | zone_devices | 0100 || {'zone_type': '00', 'zone_idx': '01', 'device_role': 'zone_actuator'}
RP | zone_devices | 0100 || {'zone_type': '00', 'zone_idx': '01', 'device_role': 'zone_actuator', 'devices': ['04:041290', '04:041302', '04:041292']}
… you’ll see that the controller believes that TRV 04:041292 is an actuator in that zone.
But later, we have 04:041292 popping up again:
RP | zone_devices | 0508 || {'zone_type': '08', 'zone_idx': '05', 'device_role': 'rad_actuator', 'devices': ['04:041292']}
This latter packet, being processed after the former, is considered corrupt. If they were processed in the reverse order (and they could be), then the packet for zone 0x01 would be dropped instead.
Your next step, assuming 04:041292 should be in zone 5, and not zone 1, is to destroy zone 1 and re-create it, then restart HA without restoring the cache.
There may be other issues, but I cann see such in the packet log you have sent me.
I --- 18:201223 63:262142 --:------ 7FFF 023 00110189B8B1482C32324631204932393A30383330343
The three ‘puzzle’ packets preceding the impersonated packet are intentional - they’re of no consequence to you (i.e. they won’t be the cause of any of the issues you describe) - they serve a useful function for ramses_rf, and can be ignored.
Yes, but why bother - the RQs are only being sent when you ask them to be.
Other packets (RQs or other) as sent by ramses_rf will eventually stop, when the destination device fails to respond (and this cycle repeats every 24h).
Yes, although there are some vagaries here - I have just spent 2 months addressing that can of worms & will be releasing a new library soon that can manage this properly. BTW, some devices require other packets, after the handshake, for the bind to be accepted by the FAN (e.g. Nuaire).
In any case, you don’t need to - simply impersonate your existing remote as I described before…
Or do you have a second ventilation unit?
Please be clear in your exact language. You are saying they work fine, but they do not?
Specifically: what you need to see is a packet Tx by one dongle is being Rx by the second dongle (which proves the Tx did happen, and it wasn’t just an echo). If that is the case, and if the impersonated packet is identical the the packet sent from the real switch (ignoring the first three digits, which are an RSSI), then you should really wait until you get your hands on a SSM-D2.
If you want help with the hardware, or with the evofw3 FW, you’ll have to ask Pete at ghoti57/evofw3 - I cannot help.
I would like to ask the community for help so that I can make switch/remote faking a first class citizen.
Above is a portion of a packet log of a switch (a type of remote) binding to a FAN (a ventilation unit).
It follows an I-W-I pattern with the command code 1FC9.
For those who have the technical ability, I would like a packet log of any such binding you can send me, so that I can build a test suite for them, and get fully-faked (i.e. virtual) switch/remotes working properly…
However, your contributions must be rigorous, and the above packet log is not sufficient.
They need to satisfy the following criteria:
10E0 packet for both devices (see below), if any.For example, note the 10E0 & 1060 packets that were spontaneously sent shortly after the binding handshake, below:
# Nuaire Switch binding to a PIV:
# - remote is a Nuaire Drimaster-ECO 4-way switch (DRI-ECO-4S) - battery powered only
# - ventilation unit is a Nuaire Drimaster-ECO PIV (DRI-ECO-HEAT-HC)
2023-04-27T16:21:21.104315 ... I --- 32:208628 --:------ 32:208628 1FC9 018 0022F1832EF46C10E0832EF4001FC9832EF4
2023-04-27T16:21:21.163187 ... W --- 30:098165 32:208628 --:------ 1FC9 006 2131DA797F75
2023-04-27T16:21:21.183713 ... I --- 32:208628 30:098165 --:------ 1FC9 001 21
2023-04-27T16:21:21.263244 ... I --- 32:208628 63:262142 --:------ 10E0 030 000001C85A01016CFFFFFFFFFFFF010607E0564D4E2D32334C4D48323300
2023-04-27T16:21:21.389080 ... I --- 32:208628 --:------ 32:208628 1060 003 00FF01
2023-04-27T16:21:21.541071 ... I --- 32:208628 --:------ 32:208628 1060 003 00FF01
2023-04-27T16:21:21.690073 ... I --- 32:208628 --:------ 32:208628 1060 003 00FF01
# The 10E0 packets:
2023-04-27T16:21:21.263244 ... I --- 32:208628 63:262142 --:------ 10E0 030 000001C85A01016CFFFFFFFFFFFF010607E0564D4E2D32334C4D48323300
2023-04-13T10:43:39.077524 ... I --- 30:098165 63:262142 --:------ 10E0 038 000001C9001D006CFEFEFFFFFFFF120707E3425244472D30324A415330310000000000000000
Useful commands might include:
cat *.log | grep -E ' 1FC9 ' -B3 -A7
cat *.log | grep -E ' (I|RP).* 10E0 '
Just post the logs here, or PM me if you prefer.
I shoudl have said, the above applies to anyone with HVAC kit, such as :
… and others.
Thanks for this
RE: the .storage/ramses_cc file - I’ve only just learned that .storage is a hidden folder & wasn’t visible in File Editor. For anyone in future, this can be edited in Settings -> Add-Ons -> File Editor -> Configuration & remove .storage from the Ignore Pattern combobox.
Yes I had errors similar to those, and had already attempted to delete one of the zones & re-bind which didn’t seem to have any effect.
I didn’t appreciate the re-binding didn’t remove it from old zones - indeed I’ve swapped some heads around recently as we reworked some zone layouts & added radiators after a cold winter…
As a belt & braces approach I unbound each head from both zones 1 & 5, (long press 10 seconds on bind button for HR91), deleted the zone, then re-added the zone but suffixed the name with a 2.
Reboot HA with restore_cache: false let it rebuild the schema, set restore_cache: true after a few hours.
I will remove the _2 suffix once I’ve cleared out any deprecated entities attribute to the original zones.
I’ve probably gone over the top with some unnecessary steps which may or may not have had an effect, but it got the job done.
Thanks for all your help David!
a short update
usgin the SSM-D2 instead of self made setup solved the issue. HVAC working without any issues.
Hi there,
This post is over 2 years old, but I just started using ramses and I want to use EvoGateway to connect to Home Assistant. My EvoGateway is merrily sending to MQTT but now I want to integrate this in HA.
Did you do that and if so, would you like to share how you did it (PM is fine as well)
Thanx.
Just embarking on integration of this having had the nanocul module for two years and following the project.
I have the official Evohome integration and its working fine and don’t wish to break that.
As its been a while since I last followed this and there seems to be numerous updates and there are nearly 3.5k entries in this post.
A few questions:
Do I have to disable the existing official integration through testing process?
I have updated the Nanocul firmware using the EvoFW3, it seemed to work. Is there any windows software that will allow me to test if its sniffing anything?
The Hacs repository seems not to find Rameses. Has the name changed?
Any other initial advice appreciated.
Thanks