update 02.00.17.00 and 02.00.17.03 - heat demand per zone (in settings)-explain this

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • Hoppy
    Automated Home Lurker
    • Nov 2017
    • 8

    update 02.00.17.00 and 02.00.17.03 - heat demand per zone (in settings)-explain this

    Get home tonight and IFTTT hadn't triggered my central heating (issues on and off since 25 Jan). Nothing to do with evohome I suspect, Philips Hue outside lights didn't come on tonight either (maybe IFTTT issue or phone data / local mast down / location issues on phone etc).

    However, it caused me to scrutinise evohome. I got home and turned the central heating on via my phone, demand was every rad throughout the house as heating had been off all day, but the heat demand per zone showed no demand in my kitchen (yet kitchen rad was hot hot hot). Is this another example of Evohome UI / software clunkiness (despite being very good in function) or am I missing something again?


    Last edited by Hoppy; 2 February 2018, 09:26 AM.
  • dty
    Automated Home Ninja
    • Aug 2016
    • 489

    #2
    Is it possible that the kitchen radiator had recently turned off and was still full of hot water?

    Also, consider that there might be an issue with the valve closing fully.

    Comment

    • DBMandrake
      Automated Home Legend
      • Sep 2014
      • 2361

      #3
      I noticed the same thing a few days ago.

      Heating manually turned on after we had been away, so naturally all zones came on to 100% for quite a while, except three of the zones reported 0% in the new heat demand diagnostic screen despite the radiators being red hot and the valve position on the HR92's reporting 100% open. I meant to post about it here but forgot.

      After about 20 minutes two of the three changed from 0 to 100% in the heat demand screen and then some time later (not sure how long) the third one finally said 100% as well.

      My conclusion based on this, and other similar observations is - when the heating was first turned on, all of the HR92's would have been told to change set point at about the same time (within a second or two of each other) so they all wind themselves from 0 to 100% pin position, which takes approx 20-30 seconds.

      We know HR92's don't send an updated heat demand until they finish adjusting their valve position. What I think happened is that all of the HR92's in the house (depending on exactly how long it takes them to wind the pin open) transmit their new 100% heat demands at almost the same time if they take the same time to go from 0-100% pin travel. And if you are unlucky, some will choose to transmit at the exact same instant and their transmissions will collide.

      So I believe in my case the three zones that stayed at 0% for 20 or so minutes suffered over the air collisions of their heat demand messages. About 20 minutes later they will send a repeat of the heat demand (even though it is still 100%) and the controller is now aware of the correct heat demand from that zone.

      The more HR92's you have and the more zones that change set point at the exact same time the higher the chance of a collision like this occurring as heat demand messages are not scheduled for regular transmission windows but are sent any time the HR92 moves its valve position. (Including in response to the owner turning the dial on the top)

      If you use optimal start individual zones will come on at different times so the chance of a collision is nearly non-existent however if you don't use optimal start but do have many zones scheduled on at the same time, or you use the away mode or heating off modes manually then cancel it there is a chance of this happening.

      The end result is nothing user visible in this case though - as long as at least one zone is demanding 100% the boiler demand will be 100%, so you wouldn't even know it happened except for the heat demand diagnostic screen. After a while the lost messages will be resent and everything will fall into line.

      This sporadic loss of messages is inevitable in a system that does not use an acknowledgement based communications protocol to confirm that messages were received, but the system is also designed to be resilient in the face of occasional lost messages, primarily by periodically resending the same message, eg heat demand, set point or measured temperature, even if they remain the same.
      Last edited by DBMandrake; 2 February 2018, 10:36 AM.

      Comment

      • radar2016
        Automated Home Jr Member
        • Mar 2016
        • 43

        #4
        I have a strange problem that has been happening for the last week.
        On schedule screen one room is showing 21 (orange) and on the edit screen it is also showing 21
        On the general display all rooms are displayed correctly but this particular room is showing 7 (Blue) and radiator is cold until I manually change it either on the controller or my iPhone then the water flows almost immediately and the pin seems as free as the other rooms
        I have swapped the units from other radiators and get same result, my first thought was the trv but as soon as I change the setting the water flows and it shows 100%.
        Now the strangest part is that this operates perfectly after that for the rest of the day, next morning cold radiator even an hour after it was supposed to change to 21

        Comment

        • chrisgare
          Automated Home Guru
          • Dec 2013
          • 182

          #5
          Simon, yes this is the same issue I've had since the upgrade and I agree it's caused by RF clashes. No great issue though in practice as things sort themselves out in due course.

          Comment

          • Hoppy
            Automated Home Lurker
            • Nov 2017
            • 8

            #6
            Cheers, I guess that makes sense

            Comment

            Working...
            X