The first is a restored packet - it was annotated by the parser when it was saved before shutting down (& subsequently restarting) HA. Everything after the # is a comment & is ignored. The RSSI number is replaced with ... becuase it wasn’r ‘received’ via RF.
I’d say that’s why its timing out - although it is ‘loaded’ at 09:33, it is timestamped as something well before that. These packets normally ‘expire’ after an hour.
Sadly no. The controller also doesn’t update anymore.
Yes, it works perfectly on version 0.9.3. After every test I downgrade to this one and then all my sensors getting there information. The Payload error shows also in this version, but it functions without problems.
I will send you my packetlog from 0.16.14. Do you still need the one from the old version? It is no problem, just have to restart the system for a clean build.
Yes, I got what I wanted. You can restore your zone to the two TRVs.
This is the relevant packet (I have added - and = for readability):
RP --- 01:050858 18:141846 --:------ 000C 016 00=00-0010D8DA-00-0010D92A-00-0010D8C0
It is 6 + 5 + 5 bytes instead of 6 + 6 + 6… This presents a small challenge (1x6B + 6x5B, 36 bytes for 7 TRVs) == (6x6B, 36 bytes for 6 TRVs) - how do I tell the difference?
What make/model controller do you have?
Yes. It functions as the heating_control, but is definitely configured as a heating_valve.
Generally speaking, ramses_rf becomes more exacting as I learn more about the protocol over time… I wonder if this has a part to play.
There will be no plans to ‘weaken’ these tests of validity, only to ‘tune’ them as required.
No - the packet log format is unchanged since nearly 2y ago - it contains every packet seen by the HGI, regardless of filter lists, and regardless if valid (or not).
So the 1st generation monochrome mode - it only supports 8 zones.
I have a TRV that never creates a temperature sensor. It creates the ones for the battery and the window status, but never one for the temperature.
The latest version, or the config changed you sent by PM appears to have resolved by heating relay status not reporting consistently. Probably need to run a bit longer to confirm that.
Had not realised you wanted full 24hr set of logs, but will send these through tomorrow.
Someone has PM’d me & I think I should post my response for the benefit of all:
The reality is this:
these errors were previously logged as INFO, and you wouldn’t have seen them by default
I’ve just switched them to a WARNING & you’ll now see them by default
in all likelihood, these errors were always there, you just didn’t have visibility on it (a detailed look in your packet logs will support/refute this - you’ll see RQs without corresponding RPs)
The change in logging is there to make you aware why things may not be behaving as you might expect.
In the specific a case of an OTB, it may not matter as much because it is polled every 60 seconds.
I’m monitoring the packets with a second evofw3 as a sniffer and see that the evofw3 that I’m using as HGI is missing almost all packets from coming from my HR92 that is in the attic.
The controller it self can receive the packets, but the evofw3 (even when directly next to the controller) is missing all packet coming from the HR92 in the attic
I already tried moving the evofw3 around the house and the only spot I can find with reception for all EvoHome devices is somewhere in a spot where you don’t want a rpi
I also tuned both evofw3 sticks and they are receiving the same packets when they are close to each other.
Clearly the pigtail antenna is not the best recipient
While I’m waiting for a stick with a SMA connector and a external antenna, I was thinking of building a simple repeater that filters only the packets coming from the problematic HR92 and injecting these some how in to the Ramses_rf module.
Is there a option to inject packets to ramses_rf with a command?