smar000 / evoGateway

Python script for listening in and responding to evohome heating control radio messages
46 stars 17 forks source link

Question: Heat demand information #42

Closed Maikel-K closed 1 year ago

Maikel-K commented 2 years ago

Hi,

Question: Im sending the data to MQTT which seems to be working fine. But if im looking into the data i can see heat demands coming by, but how to interpert this data?

i see for example: Heat demand 0.46, is this 46%? Relay demand 0.25, is this 25% Modulation level 0.0 is this 0%?

And what do the % values then reflect? My boiler is on/off controlled.

I would really love to get inside information about which zone is requesting heat and what the request to the BDR91 for my boiler is.

smar000 commented 2 years ago

Heat demand 0.46, is this 46%? Relay demand 0.25, is this 25% Modulation level 0.0 is this 0%?

Yes, those are fractions out of 1.0, and so 0.46 = 46%.

And what do the % values then reflect? My boiler is on/off controlled.

I believe that is the percentage of time that demand is coming from your boiler relay but am not 100% sure. Probably better to ask David (ramses_rf developer) as he is an expert on the protocol.

Maikel-K commented 2 years ago

Hi smar000,

Next question: I have run the eavesdropping mode a few times to see if i could get more info regarding heat requests.

It has detected my 4 TRV zones correctly and i see the temperatures coming in just fine. The only problem i have is from 2 zones im missing the trv info(when looking in MQTTexplorer for example. Any idea what this could be causing that? I also am not seeing it in the ssh on my PI.

For one room im seeing this: 2022-01-26 15:47:20 |092| TRV Kamer voor -> CTL Controller | I| heat_demand | 100% @ Kamer voor [Zone 03 ]

with this topic in MQTTExplorer: evohome/evogateway/kamer_voor/trv_kamer_voor/heat_demand/heat_demand

But for the other rooms im missing the TRV info.

These is the devices.json file: { "01:046829": { "alias": "Controller" }, "04:048533": { "alias": "Slaapkamer" }, "04:048541": { "alias": "Kamer voor" }, "04:048543": { "alias": "Kamer achter" }, "04:048531": { "alias": "Slaapkamer S" }, "13:017176": { "alias": "BDR Bijkeuken" }, "13:055321": { "alias": "BDR Badkamer" }, "13:054802": { "alias": "BDR Woonkamer" }, "13:220620": { "alias": "BDR Ketel" }, "18:000730": { "alias": "evoGateway" }, "34:032877": { "alias": "Thermostaat Bijkeuken" }, "34:103031": { "alias": "Thermostaat Badkamer" } }

this is ramses scheme: { "schema": { "controller": "01:046829", "system": { "heating_control": "13:220620" }, "orphans": [], "stored_hotwater": {}, "underfloor_heating": {}, "zones": { "00": { "_name": null, "heating_type": "zone_valve", "sensor": null, "devices": [ "13:054802", "01:046829" ] }, "01": { "_name": null, "heating_type": "radiator_valve", "sensor": "04:048533", "devices": [ "04:048533" ] }, "02": { "_name": null, "heating_type": "radiator_valve", "sensor": "04:048531", "devices": [ "04:048531" ] }, "03": { "_name": null, "heating_type": "radiator_valve", "sensor": "04:048541", "devices": [ "04:048541" ] }, "04": { "_name": null, "heating_type": "zone_valve", "sensor": "34:103031", "devices": [ "13:055321", "34:103031" ] }, "05": { "_name": null, "heating_type": "zone_valve", "sensor": "34:032877", "devices": [ "13:017176", "34:032877" ] }, "06": { "_name": null, "heating_type": "radiator_valve", "sensor": "04:048543", "devices": [ "04:048543" ] } } } }

and this is zones.json: { "00": "Woonkamer", "01": "Slaapkamer", "02": "Slaapkamer S", "03": "Kamer voor", "04": "Badkamer", "05": "Bijkeuken", "06": "Kamer achter" }

smar000 commented 2 years ago

You will have to do a bit of investigative work to determine if the missing data is due to (i) evogateway (possible, though I would be surprised as I am not seeing it), (ii) ramses_rf (unlikely) or your (iii) your hardware (quite possible).

To check for evogateway, check your packet log and see if there are corresponding entries there for your missing data (search on device id, and some of the ramses response codes for the missing data). If you do find the packets there, then the problem is with my code.

If not, next step is to use the ramses_rf cli and run that for a while to see if you get the packet data.

Final step is to check your hardware. You may want to try running the 'tune' option for the CC1101 - see the arduino firmware repo for instructions on how to do this.

Maikel-K commented 2 years ago

I placed the unit in a different location and I'm seeing that info now. So maybe it couldnt pickup the signal of the TRV but the main controller could recieve the messages okay(the TRV shows 3 bars on the display)

Could that be true? That the TRV info if also sniffed from the evoGateway separately?

I also want to know how the Evohome requests heat to the boiler but maybe I can find that in the Ramses_rf protocol

smar000 commented 2 years ago

Yes I have seen changing locations can help. As far as I understand it, these 'fake' HGI devices are not as powerful as the original Honeywell devices and also have frequency consistency issues (hence the need to tune them).

I also want to know how the Evohome requests heat to the boiler but maybe I can find that in the Ramses_rf protocol

Not sure what you mean here, but yes, definitely lot more info on this side of things on the ramses_rf repo.