Page 2 of 2 FirstFirst 12
Results 11 to 16 of 16

Thread: eBus monitoring

  1. #11
    Automated Home Jr Member
    Join Date
    May 2017
    Posts
    15

    Default

    So it turns out a bad connection between the usb/ebus converter and the boiler was the cause of some dodgy readings.

    A little bank holiday reading and around 100 lines of python code has produced something that I can start to work with.

    Boiler_Dashboard.jpg

    Thanks to @jdp80 for some script "getting started" pointers

  2. #12
    Automated Home Ninja
    Join Date
    Aug 2016
    Posts
    489

    Default

    Sorry I didn't reply to this - I've been away for a few weeks. Looks like you've got it going now.

    I don't use a script any more. I have a flow in NodeRed which gathers the data I want (and cleans it) and puts it into InfluxDB.

  3. #13
    Automated Home Jr Member
    Join Date
    May 2017
    Posts
    15

    Default

    Bringing back the old thread rather than start a fresh...

    I've had the current monitoring going for a while now, have added the functionality to read the fault log from the boiler as well and I'm pretty happy.

    Next step is that I've decided to make the jump to OpenTherm, and have order the VR33 and EvoHome OpenTherm module. Can anyone with this setup confirm if FlowTempDesired is still the register with ebusd to monitor to see what calls are being made to the boiler (I'm expecting this value to change, rather than stay fixed as it does now) or if I should be looking at something else?

    As an aside, what registers are others monitoring? I'm really keen on seeing actual heat output (in kw) the boiler is producing (i.e - when the flame icon on the display ramps up), as so far have only managed to find HeatingPartLoad, which (again) stays fixed at the value I've set on the boiler.

    Thanks

  4. #14
    Automated Home Ninja
    Join Date
    Aug 2016
    Posts
    489

    Default

    I monitor the following:

    FlowTemp, ReturnTemp, StateNumber, Flame, WP, WaterPressure, RemainingBoilerblocktime, FlowTempDesired, TargetFlowTemperature, ModulationTempDesired

    I extract using the following: read -m 15 -V <variable>

    I parse the response as follows: If it starts with 'ERR:', drop it. If it is 'on', return 1. If it is 'off', return 0. Otherwise, try and parse the response as a number. If that fails, drop the response.

    So, now I have a variable and a number. I apply the following rules:

    Power: if Flame is 1, ModulationTempDesired * 0.3, else 0. My boiler returns either the last value for this variable, or else the smallest observed non-zero value for this variable if the flame is not on. That skews any analysis I do about output power, so I force it to 0 if the flame isn't on. The 0.3 comes from observation. I turned the hot water on, observed how high this went, and calculated the 0.3 based on my boiler's power. My 25kW boiler gets to 83.3333, and goes as low as 20 (which represents 6kW, which is right). I didn't find a better way to capture the output power, and other people with different boilers have reported that this approach didn't work for them.

    DeltaT: max(0, FlowTemp - ReturnTemp). Sometimes (when the pump is on, and the flame off) my system reports a flow temp lower than the return temp which results in a negative number here. This is technically correct. Why I have this situation, I don't know - I expect it's because of my low loss header.

    Condensing: if Flame is 1 and ReturnTemp < 55, set this to 1, otherwise 0. This is a horrible rule-of-thumb.

    Then I rename the following:

    WP -> Pump. WP means "Water Pump", I think. It corresponds to the pump being on or off, either way!
    TargetFlowTemperature -> RequestedFlowTemp. This is the flow temperature being requested by eBus.
    FlowTempDesired -> TargetFlowTemp. This is the temperature the boiler is trying to achieve. This is the same as the requested flow temperature, except it's limited by the configured maximum flow temperature. So, when EvoHome requests 90, this will be 70.
    RemainingBoilerblocktime -> RemainingLockoutTime.

    Other variables get copied over unchanged. This results in the following (JSON):

    Code:
    {
      "FlowTemp":75.06,
      "ReturnTemp":66.06,
      "StateNumber":4,
      "Flame":1,
      "WaterPressure":2.01,
      "Power":12.27,
      "DeltaT":9,
      "Condensing":0,
      "Pump":1,
      "RemainingLockoutTime":0,
      "RequestedFlowTemp":90,
      "TargetFlowTemp":75
    }

  5. #15
    Automated Home Legend
    Join Date
    Jul 2014
    Posts
    1,002

    Default

    All I would add is that, one of the best uses of being hooked on the eBus and Evohome, is being able to vary the flow temperature when there is HW demand.

    In terms of my experience with ModulationTempDesired is that, the multiplier you use depends on the Range rating. What worked for my 438 When it was 28kw, didn't work for when it was set to 18kw. What was surprising was that at 18kw, my boiler seemed to modulate lower, than when it was set to 28kw. I don't have an AUTO range setting on my boiler unfortunately. I would say, before you add any multiplier, just capture the raw data for a while an observe the max and min, before applying a the multiplier. Also don't be surprised if the boiler goes to 0 just before firing up. Don't know why the boiler reports it that way. Normally the low end is the constant that the boiler will sit at over night when there is no heat demand.

  6. #16
    Automated Home Jr Member
    Join Date
    May 2017
    Posts
    15

    Default

    Thanks both for the pointers. Hopefully the VR33 will arrive next week and I'll have a play.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •