Hi @zxdavb I have a HGI80. i was trying to set up a fake temperature sensor, not an impersonation. Not sure if I can transmit, so far the evohome does not respond to any binding attempts.
Sorry, I wasnât very clear.
A HGI80 can fake (e.g. pretend to be a temperature sensor), but it cannot impersonate (send packets with a source device id other than its own).
You may be successful if you give your faked sensor the same device id as the HGI80âs real device id. IIRC, but I suspect not.
Faking with a HGI80 is problematic - I am aware of how Bruce made it work in Domoticz, but itâs simply not that easy in HA because of the internal architecture of ramses_rf.
Sorry, but I am really unsure if ramses_rf will ever support it at all because not enough people have HGI80s to make the effort worthwhile (FWIW, I have one).
Even if I did get it working, you could only have one faked device of each class (because you only have one source device id to play with).
With evofw3 you have none of these limitations, and a high-quality evofw3-compatible dongle is about ÂŁ35.
Almost all my effort is being directed towards making the sensor/remote faking UX, watch this space!
Hi David,
Thanks for explaining, now I know what to do. I just ordered a evofw3 dongle. I want to impersonate 5 temperature sensors. Thanks for building this integration!
This is my Thermal Store Temp sensor. its a Evohome CS92 sensor. it continually goes unavailable.
Evohome still sees it fine.
Its possible its on the limits of reach although there is a more direct route to the attic for the evofw3 to the sensor.
You can see its can be very stable so not sure if that is the cause.
The issue is the sensor goes unavailable and then any last know temp is not visible on my cards using it. Thoughts?
I installed 0.30.9 yesterday.
This is in the log this morning.
2023-12-27 08:31:19.087 WARNING (MainThread) [homeassistant.helpers.entity] Updating state for binary_sensor.01_196480_schema (<class 'custom_components.ramses_cc.binary_sensor.RamsesSystem'>) took 1.700 seconds.
Anything to worry about?
Here is another warning I sometimes see. I wouldnât mind an understanding of what it is telling.
2023-12-27 14:46:16.501 WARNING (MainThread) [ramses_tx.protocol] *** sync cycle stats: 0.011, avg: 0.034, lower: 0.011, upper: 0.083, times: ['0.022', '0.055', '0.043', '0.083', '0.012', '0.011', '0.011']
Going through my HA log and saw this:
2023-12-28 10:03:11.055 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 716, in async_update_ha_state
self._async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 845, in _async_write_ha_state
state, attr = self._async_generate_attributes()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 789, in _async_generate_attributes
attr.update(self.extra_state_attributes or {})
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/ramses_cc/binary_sensor.py", line 226, in extra_state_attributes
"known_list": [{k: shrink(v)} for k, v in gwy.known_list.items()],
^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_rf/gateway.py", line 657, in known_list
{
File "/usr/local/lib/python3.11/site-packages/ramses_rf/gateway.py", line 658, in <dictcomp>
d.id: {k: d.traits[k] for k in (SZ_CLASS, SZ_ALIAS, SZ_FAKED)}
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_rf/gateway.py", line 658, in <dictcomp>
d.id: {k: d.traits[k] for k in (SZ_CLASS, SZ_ALIAS, SZ_FAKED)}
^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_rf/device/heat.py", line 1197, in traits
"opentherm_traits": self.supported_cmds_ot,
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_rf/entity_base.py", line 362, in supported_cmds_ot
return {
^
File "/usr/local/lib/python3.11/site-packages/ramses_rf/entity_base.py", line 363, in <dictcomp>
msg_id: OPENTHERM_MESSAGES[int(msg_id, 16)].get("var")
~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
KeyError: 159
Running version 0.30.9
Config:
ramses_cc:
serial_port: /dev/serial/by-id/usb-Texas_Instruments_TUSB3410_Boot_Device_TUSB3410-if00-port0
restore_cache: true
#restore_cache: # Required to add new device
# restore_schema: false
# restore_state: true
scan_interval: 60
packet_log:
file_name: /config/ramses_cc_packet.log
rotate_bytes: null
rotate_backups: 7
ramses_rf:
enable_eavesdrop: false
enforce_known_list: true # Set false to add new device
01:223036:
system:
appliance_control: 10:040239
zones:
"00": { sensor: 01:223036 }
known_list:
01:223036: # Evohome (Temperature control system)
04:231770:
04:231772:
04:231774:
04:231776:
04:050559:
04:155445:
04:155403:
04:081849:
04:155407:
04:155551:
04:155533:
04:155537:
04:017541: # Slaapkamer
10:040239: # OTB
18:005567: # Honeywell HGI80
I would say simply a corrupt packet that wasnât handled gracefully.
AFAIK, there is no OT msg with a data-id of 159.
If you can get me the original Traceback, that would be helpful. All but the first will look this the above.
I could share the log?
Actually, donât bother. I can work it out (and there wonât be an 'original Traceback).
What I want to see is the output of:
cat packet.* | grep -E ' 3220.* ..9F'No results for
cat packet.* | grep -E â 3220.* âŚ9Fâ
Sorry: grep -E ' 3220.* 00..9F'
2023-12-27T23:39:36.010587 045 RP --- 10:040239 18:005567 --:------ 3220 005 00C09FFFFF
Hi Rinco,
here it is.
type: custom:stack-in-card
cards:
- type: custom:mini-graph-card
entities:
- entity: sensor.32_143323_indoor_humidity
name: Kitchen
show_state: true
show_points: true
show_fill: true
show_label: true
show_line: true
height: 50
hours_to_show: 48
smoothing: true
points_per_hour: 6
line_color: lightblue
line_width: 0.5
show_fill: false
label: false
animate: true
show:
name: false
icon: false
state: false
legend: false
fill: true
labels: false
labels_secondary: false
points: true
card_mod:
style: |
ha-card {
position: absolute !important;
height: 100%;
width: 100%;
top: 0px;
--ha-card-border-width: 0;
- type: picture-elements
image: local/wtw_enabled.gif
elements:
- type: custom:mushroom-chips-card
chips:
- type: entity
entity: sensor.32_143323_supply_temp
icon_color: red
use_entity_picture: false
style:
top: 61%
left: 13%
alignment: right
- type: custom:mushroom-chips-card
chips:
- type: entity
entity: sensor.32_143323_supply_fan_speed
icon_color: red
use_entity_picture: false
style:
top: 71%
left: 13%
alignment: right
- type: custom:mushroom-chips-card
chips:
- type: entity
entity: sensor.32_143323_indoor_temp
icon_color: grey
use_entity_picture: false
style:
top: 28%
left: 13%
- type: custom:mushroom-chips-card
chips:
- type: entity
entity: sensor.32_143323_indoor_humidity
icon_color: grey
use_entity_picture: false
style:
top: 38%
left: 13%
- type: custom:mushroom-chips-card
chips:
- type: entity
entity: sensor.32_143323_exhaust_temp
icon_color: blue
use_entity_picture: false
style:
top: 28%
left: 86%
- type: custom:mushroom-chips-card
chips:
- type: entity
entity: sensor.32_143323_exhaust_fan_speed
icon_color: blue
use_entity_picture: false
style:
top: 38%
left: 86%
- type: custom:mushroom-chips-card
chips:
- type: entity
entity: sensor.32_143323_outdoor_temp
icon_color: grey
use_entity_picture: false
style:
top: 61%
left: 86%
- type: custom:mushroom-chips-card
chips:
- type: entity
entity: sensor.32_143323_outdoor_humidity
icon_color: grey
use_entity_picture: false
style:
top: 71%
left: 86%
- type: custom:mushroom-chips-card
chips:
- type: entity
entity: binary_sensor.32_143323_bypass_position
icon_color: grey
icon: mdi:transit-skip
use_entity_picture: false
- type: entity
entity: sensor.32_143323_fan_info
icon_color: grey
icon: mdi:fan
use_entity_picture: false
- type: entity
entity: sensor.37_007050_co2_level
icon_color: grey
icon: mdi:fridge
use_entity_picture: false
- type: entity
entity: sensor.37_006795_co2_level
icon_color: grey
icon: mdi:bed-double
use_entity_picture: false
style:
top: 90%
left: 47%
- type: image
entity: switch.wtw_plug
state_image:
'off': /local/wtw_visual_disabled.png
style:
left: 0%
top: 0%
transform: scale(1,1)
filter: saturate(0.01)
- type: custom:mini-graph-card
entities:
- entity: sensor.37_007050_co2_level
name: Kitchen
show_state: true
show_points: true
show_fill: false
show_label: true
show_line: true
- entity: sensor.37_006795_co2_level
name: Master bedroom
show_line: true
show_points: true
show_fill: false
show_label: true
- entity: input_number.wtw_stand
color: grey
name: humidity
show_fill: true
show_line: false
y_axis: secondary
show_state: true
show_points: true
show_label: true
height: 50
hours_to_show: 48
smoothing: true
points_per_hour: 6
line_width: 1
show_fill: false
label: false
animate: true
show:
name: false
icon: false
state: true
legend: false
fill: true
labels: true
labels_secondary: false
points: true
color_thresholds:
- value: 100
color: '#02C741'
- value: 600
color: '#48D800'
- value: 1000
color: '#EF9101'
- value: 1500
color: '#E72000'
card_mod:
style: |
ha-card {
position: ;
height: 100%;
width: 100%;
top: 0px;
--ha-card-border-width: 0;
Is an aberrant packet that should not have been cached.
If youâve bought a nanoCUL. First thing is to flash it with the latest evofw3 with the Arduino IDE.
Please let me know what settings you use. I have followed these instructions and then used:
For re-flashing evofw3 via Arduino IDE on *my* atmega328p (YMMV):
- Board: atmega328p (SW UART)
- Bootloader: Old Bootloader
- Processor: atmega328p (5V, 16 MHz)
- Host: 57600 (or 115200, YMMV)
- Pinout: Nano
Then, use that same baud rate in your config. SOmething like:
ramses_cc:
serial_port:
port_name: /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
baudrate: 57600
I appreciate the above instructions are very brief, I may write a wiki page if required.
Does that mean you got it working?
If so - could you tell us what the issue is, so I can make sure to have it in the wiki?
ramses_rf is very chatty. If it Tx whilst the evohome controller is Tx its periodic sync cycle (every 3 minutes or so), then the evohome devices wont get this data.
So it predicts when the next cycle is due, and does not Tx during this time.
This is debug code that list the difference between the predicted and actual cycle lengths.
There must be a way of packaging this with ramses_cc!
Hi!
I bought one preflashed with evofw3 from Schlauhaus. nanoCUL 868 MHz. i thought it didnt work properly, but it was just a faulty cable. Hence the deleted message, because I thought itâs just a bit of noise from my part.
It works out of the box, no baud rate setting required.
1 Like