Honeywell CH/DHW via RF - evohome, sundial, hometronics, chronotherm

[zxdavb (David Bonnes)]

@prescott

@zxdavb If you wanted to determine which zone is the most guilty of boiler firing, how would you do it? Which state would you measure?

The best measure is zone heat demand - plot over time, it alongside zone setpoint.

[zxdavb (David Bonnes)]

@TheMystery

Question not directely related with ramses_cc but maybe with the protocol.

I know the RAMSES protocol very well - what the devices are saying. I know less about what Honeywell evohome kit is thinking (others know more than me) and, FWIW, I knew even less about non-Honeywell kit.

A better place to get such answers may be at this forum:
https://www.automatedhome.co.uk/vbulletin/forumdisplay.php?13-Heating-Control

@TheMystery

I have a few time a year that there is no heat demand when it should be.
Today i have 1 room on 19.5 setpoint and the real temperature is 18.6.
But there is no heat demand on the room or on the hr92 or on the controller or bdr91.

This is a thinking question… For example, I believe that the 18.6 may be rounded up to 19? Then, if the TRV has a pin valve position < 60 (out of 0-200, i.e. <30%), this translates into a zone demand of 0%.

All other demands (zone, boiler) flow from TRV demand, so a TRV demand of 0% is the proximal cause.

@TheMystery

someone having this problem before and knows what it can be?

I think, maybe just the fuzzy logic - if you remove / replace the batteries, it simply start with ‘default’ fuzz.

I wonder if we are spending too much time looking at the dog’s tail? Really, the question is: does the room feel cold? If so: is it simply a matter of raising the setpoint?

(FWIW, I believe that everyone should have zone sensors - they can resolve a lot of this sort of nonsense)

I think it is OK to look at this detail if sometime is going ‘wrong’, but if everything is OK,

[zxdavb (David Bonnes)]

BTW, it may be enough just to search that forum, rather than ask a new question - all this stuff has been asked there before.

[TheMystery (Johnny)]

Thx, i will look in that forum didn’t know that one.

But even if i set setpoint on 22 degreed there is no heat demand on the controller itself nor in the ha entities. So strange problem.

[tomkooij]

Today the outside temperature went below 0 degrees:

Orcon fan:
2022-11-20T08:32:06.904058 063 RP — 32:134446 37:171685 --:------ 31DA 030 00EF007FFF2F1B0226069A07EEFFE4F8000038988F0000EFEF1F2420FC00

EDIT: I fixed the temps:
Temperature FEE4 should be -0.28 degrees.

BUG: This is interpreted as 650 orso degrees. Signed/unsiged.

I submitted a PR: Negative temperatures by tomkooij · Pull Request #65 · zxdavb/ramses_rf · GitHub

[Kars (Kars de Jong)]

Yes, noticed the same here. Thanks for reporting it.

[Tyfoon]

I also finally want to jump on this RF train for EvoHome. In know this is the recommended hardware, but could someone share what would be the best current EU based alternative?

[zxdavb (David Bonnes)]

@tomkooij

Today the outside temperature went below 0 degrees:

Temperature FEE4 should be -0.28 degrees.

BUG: This is interpreted as 650 orso degrees. Signed/unsiged.

I submitted a PR:

Merged. Thanks.

[zxdavb (David Bonnes)]

Version 0.22.2 released. All bugfixes:

In ramses_cc, from 0.22.2:

• b2aed159ec: limit packets restored by restore_state: true so that restore_schema: false works as intended
• 9cf5e63b5d: add in missing service call selectors in services.yaml
• c375718e99: fix regression in send_packet service call when used with a real HGI80

In ramses_rf, from 0.22.2:

• cc82032: handle negative (e.g. outside) temperatures correctly in 31DA (for HVAC)
• 471db6e: bugfix mode validation for set_xxx_mode() APIs (used by ramses_cc service calls)

[zxdavb (David Bonnes)]

I would be grateful if some people could spare the time to test all the service calls (there has been a lot of fixes).

[Lloyd (Lloyd Adams)]

@zxdavb Looks like 0.22.2 has broken send_packet. This was working before yesterday’s releases.

2022-11-21 12:42:35.939 DEBUG (MainThread) [ramses_rf.protocol.protocol] MsgProtocol.send_data( I --- 18:000730 18:136212 --:------ 0008 002 00C8)                                                                                                                                                         
2022-11-21 12:42:35.939 DEBUG (MainThread) [ramses_rf.protocol.protocol] MsgTransport.write( I --- 18:000730 18:136212 --:------ 0008 002 00C8)                                                                                                                                                            
2022-11-21 12:42:35.986 DEBUG (MainThread) [ramses_rf.protocol.protocol] MsgTransport.pkt_dispatcher( I --- 18:000730 18:136212 --:------ 0008 002 00C8): send_data
2022-11-21 12:42:36.010 DEBUG (MainThread) [ramses_rf.protocol.transport] 000  I --- 18:136212 18:136212 --:------ 0008 002 00C8 < Cant create packet (ignoring): Corrupt packet: Bad frame: invalid address set Corrupt addresses: Invalid addr set: 18:136212 18:136212 --:------
2022-11-21 12:42:36.212 DEBUG (MainThread) [ramses_rf.protocol.transport] 000  I --- 18:136212 18:136212 --:------ 0008 002 00C8 < Cant create packet (ignoring): Corrupt packet: Bad frame: invalid address set Corrupt addresses: Invalid addr set: 18:136212 18:136212 --:------
2022-11-21 12:42:36.614 DEBUG (MainThread) [ramses_rf.protocol.transport] 000  I --- 18:136212 18:136212 --:------ 0008 002 00C8 < Cant create packet (ignoring): Corrupt packet: Bad frame: invalid address set Corrupt addresses: Invalid addr set: 18:136212 18:136212 --:------
2022-11-21 12:42:37.391 DEBUG (MainThread) [ramses_rf.protocol.transport] PacketProtocolQos.send_data( I --- 18:000730 18:136212 --:------ 0008 002 00C8) timed out: tx_rcvd=False (retry_count=2), rx_rcvd=False (timeout=0:00:00.200000)
2022-11-21 12:42:43.608 DEBUG (MainThread) [ramses_rf.protocol.protocol] MsgTransport._pkt_receiver( I --- 04:003434 --:------ 01:185426 1060 003 046401)
.@

[zxdavb (David Bonnes)]

@Lloyd

@zxdavb Looks like 0.22.2 has broken send_packet.

Yeah - I know what this is - fix coming.

[zxdavb (David Bonnes)]

@Lloyd

@zxdavb Looks like 0.22.2 has broken send_packet.

I have restored release 0.22.1 - you will need to use it if you are using the send_packet service to broadcast packets as if from an evofw3 dongle (it doesn’t work for HGI80s).

• to be clear: a packet from a dongle/gateway to another device is not affected
• it is only an issue when the packet is being sent to the gateway from itself

If you are not using the send_packet service call at all, use 0.22.3 - it has several important bug fixes over 0.22.1.

[Tyfoon]

@Tyfoon

I also finally want to jump on this RF train for EvoHome. In know this is the recommended hardware, but could someone share what would be the best current EU based alternative?

Please? With over 3000 posts I’m sure there are people that are happy with their device and not all using the SSM-D2 (which I would need to import + is not available). Would be great if you can share.

[Spaco]

Something like this: Nano CUL 868 - smart-home-komponente

[zxdavb (David Bonnes)]

@Tyfoon

I’m sure there are people that are happy with their device and not all using the SSM-D2 (which I would need to import + is not available

You can buy anything off ebay that has “Nanocul USB FTDI CC1101 868MHz”, although you may need to load the evofw3 firmware on it. This one says thay’ll load it on for you: Nanocul USB FTDI CC1101 868MHz FW 1.67 Kink Antenna fhem cul 868+ Adapter | eBay

The recommendation from @Spaco is the same supplier as above.

A nanoCUL is nowhere as good as an SSM-D (which uses a HW UART) but will still do the job - especially after an autotune.

Or you can try to source a Honeywell HGI80, although they are difficult to find and can’t do impersonation.

Regarding supply of SSM-Ds - were are you in Europe?

[Tyfoon]

Thanks! I’m in the Netherlands

The only source of the ssm-d2 seems to be in the UK. Not a huge issue but the site mentions non available and import is now bit of hassle (time & money) which will roughly double the cost

[zxdavb (David Bonnes)]

@Tyfoon

The only source of the ssm-d2 seems to be in the UK.

Check your PM.

[Lloyd (Lloyd Adams)]

You could always assemble your own:

Arduino Micro (with headers)

Laqiya CC1101&nbsp;868MHZ RADIO Transmission Antenna Transceiver Module :...

I would recommend using a genuine Arduino micro.

[donoghdb (David)]

@Lloyd the issue with the Arduino Micro is it is 5V and the CC1101 requires 3.3V, have you used any thing to overcome this? I have ordered a ssm-d2, as my cheap pro-micro 3.3V gives up after a few hours.