This will definitely stop.
This I need to know if it happens again.
Also @maesenator can you send me a 24h packet log please - I am wondering if your system has issues at the RF layer that is exposing this (otherwise unrelated) issue.
OK, version 0.20.22a released as a beta, fixes include:
- Fan flow rates are now in L/s and not L/min or percentage
- Configured commands (in configuration.yaml) are no longer overwritten by old cached commands
- Fan state is now refreshed soon after sending a command
- Zones min/max temps now hardened against
TypeError: 'NoneType' object is not subscriptable - Changes to underlying library to (hopefully) stop other:
TypeError: 'NoneType' object is not subscriptable
When you say ‘partially’ - what can’t you do?
Version 0.20.22b has been released. Fixes some known issues.
Anyone running:
- 0.20.20+ can safely upgrade ASAP - it is as small update, essentially only bugfixes, improvements
- 0.20.x should upgrade soon - you will have to reconfigure your configuration.yaml slightly
1 Like
I’ve added config to yaml file to create a packet log. Will send it to you tomorrow after I’ve gathered 24hrs.
I need some 24h packet logs from people with Itho and Nuaire ventilation units - preferably with the remotes being used.
See here: Itho / Orco / Nuaire: Fan metrics, Remote control & Sensor faking via RF
I had the packet log, then updated to 0.20.22c while I removed the config entry for the log file, after the update finished the log file was removed.
I now have nothing.
I’ll make a new one for the next 24hrs and send it to you tomorrow.
I’ll send you the last 2 days of logs. They both should have remote button presses and service calls.
I have lots of sensors from my PIV, but most of them don’t update. Temp, humidity do, as does my Co2 sensor when it’s plugged in.
Send you a PM with 9-days of packet logs hope you will find it usefull. My system is Itho.
That’s really useful - can you send me your known_list too?
Are you still using use_regex?
No, I temporary moved to another integration for controlling my HRU. Now I have more time to try evohome cc.
This is my config:
ramses_cc:
serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
restore_cache:
restore_schema: false
restore_state: false
packet_log:
file_name: packet.log
rotate_backups: 28
orphans_hvac: [18:126620, 37:154011, 29:060945]
known_list:
18:200467: # evofw3
21:038634: {class: RFS, _note: Spider Thermostat (CCU-12T20)} # Spider (CCU-12T20)
18:126620: {class: FAN, _note: HRU ECO 300 } # HRU i guess
37:154011: {class: CO2, _note: Co2 sensor (VMS-12C39)} # Co2 (VMS-12C39)
29:060945: {class: REM, _note: Co2 Remote} # Co2 Remote
block_list:
18:114076: # Foreign gateway
Now i’m having the same issue of multiple 18:xx (more than one HGI80-compatible device message ) since my HRU has the same prefix as the gateway.
Edit:
To clarify i’m using evohome_cc (0.20.22c) now and not ramses_rf. Is there a way to use use_regex in evohome cc? Porting the yaml does not seem to work as it does not know the [use_regex] is an invalid option for [ramses_cc].
I think we’ve just got to give up on these warnings:
There appears to be more than one HGI80-compatible device (active gateway: 18:200467), this is unsupported, configure the known_list/block_list as required
use_regex is too powerful for everyday use - it is being deprecated.
Does the message get parsed regardless of this error? And since device classes can be set, why not pass through the messages which are not off class HGI?
In short, ramses_rf is split into two layers. The concept of HGI is in the upper layer, and the 18: is in the lower layer, where the checking for duplicate HGI80s is done.
Unfortunately, as the HVAC guys know, not every 18:xxxxxx is a HGI80: some of them are HVAC devices.
Generally, for:
- logged warnings: Yes, the packet is passed up to the upper layers of the protocol
- exceptions: No, the packet is not processed further.
I am working on a fix for this problem…
@dennisvbussel I have implemented a fix for:
< There appears to be more than one HGI80-compatible device (active gateway: 18:200467), this is unsupported, configure the known_list/block_list as required
It is currently the master branch - you can try that, via HACS, if you like.
Thanks! The warning is gone now.
2022-08-23 12:17:37.624 WARNING (MainThread) [ramses_rf.protocol.transport] I --- 18:200467 63:262142 --:------ 7FFF 016 00100182CA3527FE76302E32302E3239 < Active gateway set to: 18:200467
2022-08-23 12:18:19.757 WARNING (MainThread) [ramses_rf.protocol.protocol] MsgTransport._pkt_receiver(22E0|RP|18:126620): Expired callback
2022-08-23 12:18:49.818 WARNING (MainThread) [ramses_rf.protocol.protocol] MsgTransport._pkt_receiver(22E5|RP|18:126620): Expired callback
2022-08-23 12:19:01.561 WARNING (MainThread) [ramses_rf.protocol.protocol] MsgTransport._pkt_receiver(22E9|RP|18:126620): Expired callback
2022-08-23 12:19:25.819 WARNING (MainThread) [ramses_rf.protocol.protocol] MsgTransport._pkt_receiver(22F2|RP|18:126620): Expired callback
2022-08-23 12:19:35.460 WARNING (MainThread) [ramses_rf.protocol.protocol] MsgTransport._pkt_receiver(22F4|RP|18:126620): Expired callback
2022-08-23 12:19:51.734 WARNING (MainThread) [ramses_rf.protocol.protocol] MsgTransport._pkt_receiver(22F8|RP|18:126620): Expired callback
2022-08-23 12:20:21.804 WARNING (MainThread) [ramses_rf.protocol.protocol] MsgTransport._pkt_receiver(313E|RP|18:126620): Expired callback
2022-08-23 12:20:54.821 WARNING (MainThread) [ramses_rf.protocol.protocol] MsgTransport._pkt_receiver(3222|RP|18:126620): Expired callback
2022-08-23 12:21:24.795 WARNING (MainThread) [ramses_rf.protocol.protocol] MsgTransport._pkt_receiver(10D0|RP|18:126620): Expired callback
2022-08-23 12:21:54.805 WARNING (MainThread) [ramses_rf.protocol.protocol] MsgTransport._pkt_receiver(22F1|RP|18:126620): Expired callback
2022-08-23 12:22:24.835 WARNING (MainThread) [ramses_rf.protocol.protocol] MsgTransport._pkt_receiver(2210|RP|18:126620): Expired callback
2022-08-23 12:22:54.824 WARNING (MainThread) [ramses_rf.protocol.protocol] MsgTransport._pkt_receiver(22E0|RP|18:126620): Expired callback
2022-08-23 12:23:24.831 WARNING (MainThread) [ramses_rf.protocol.protocol] MsgTransport._pkt_receiver(22E5|RP|18:126620): Expired callback
Do you have an idea why I get a lot of expired callback warnings?
Yes, they are for my benefit - I will remove them soon enough. Until then, you can ignore them.
So I’m finally giving up on trying to figure out why my HGI-80 will talk to my Raspberry Pi but not my Debian box. I’m gonna get a atmega328 or atmega32u4. Is one easier/better than the other or are they functionally identical? Thanks. Any other recommendations on specific hardware which is best? I’d like to just get a box with a case that I don’t have to monkey around with if possible (I hate hardware). The SSM-D2 is not in stock ATM.
You know HGI80s work only at 115200, right?
In any case, there are good reasons to get an evofw3 based system, and the SSM-D2 is the best. I am sorry, if it is not in stock - I don’t know if @arjenhiemstra is selling something compatible?
Have you tried ser2net?