Announcement

Collapse
No announcement yet.

Master Slave Operation of Virtual Thermostats Beta 3.1.0.0

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Master Slave Operation of Virtual Thermostats Beta 3.1.0.0

    Following a feature request I have been working on an updated version of SDJ-VStat which incorporates optional Master/Slave operation.

    It turned out to be pretty complex mainly because I have tried to build as much flexibility as possible into the way it works. Beta 3.1.0.0 will shortly be posted to the Beta section of the updater if anybody wants to test out the new features. I've tested this as best I can but please back your system up before installing the beta as there are some fairly fundamental changes under the hood.

    The general philosophy is that any VStat can be designated as a Slave and be assigned a Master VStat. Any number of Slaves can have the same Master and there can be any number of Masters. The only restriction is that a Slave cannot also be a Master to avoid creating circular loops.

    Each Slave can have optional parameters set to follow its Master and they can be different for each Slave. The optional parameters are:
    • Schedules
    • High SetPoint - with optional temperature offset
    • Low SetPoint- with optional temperature offset
    • Frost SetPoint- with optional temperature offset
    • Mode
    • Target Temperature
    • Boost
    • Weather Compensation
    • Open Windows
    It could be used to simply have a number of VStats follow the same 7 day schedules but otherwise be totally independent. Previously this would have required importing the same schedule into each VStat but now you can have Slaves' schedules update anytime the Master's schedules are edited or imported.

    SetPoints have optional temperature offsets so you could have a slave sync to a SetPoint of the Master but always be 0.5 degrees higher or lower, for example.

    Selecting the Mode as an option will allow you to turn a group of VStats into Away/Frost mode and back to Auto just by controlling the Master. When in Auto mode the Slaves will still follow their own schedules.

    There are some subtleties to the way the syncing works which is explained in a new section 7.1 of the guide. For example if the Target Temperature is selected, the Slave isn't actually synced with the value of the Target Temperature of the Master, if you wanted to do that you would just sync the SetPoints. It is controlled by controlling the Target Temperature of the Master. If you click the 'Increase' or 'Decrease' buttons of the Target Temperature Device on the Master it also increases or decreases the Target Temperature of the Slaves. If you input a specific value to the Target Temperature of the Master, for a temporary override (hold), that same value will be input to the Slave. However, they will return to their own SetPoints following their own schedules which may or may not also be synced.

    Setup is done on the configuration page for any VStats that you want to act as Slaves. There is a new 'Slave' checkbox on the VStat Type row. Checking this reveals a new row of Sync Options and settings as shown below.

    Click image for larger version

Name:	Slave.JPG
Views:	125
Size:	55.4 KB
ID:	1356795

    Select a Master from the drop down list and then any options and temperature offsets. Finally click the 'Sync Now' button to carry out an initial sync. Form then on the syncing will be automatic.

    You can halt or pause the syncing by deselecting the 'Slave' checkbox. The various settings are stored so selecting 'Slave' again will re-establish the previous links.

    The data structure stored in the VStat devices is updated to incorporate the additional features so the VStat-Scheduler program is also updated. This will be installed in the HS3 root folder but if you run it from elsewhere remember to copy the new version to that location.

    Whilst updating the scheduler program I made some changes so that all 7 days of schedules are displayed to the right of the form. You can still overlay any combination of days in the drawing window but the right hand view makes it a little clearer and is updated every time you release the mouse in the drawing area.

    Click image for larger version

Name:	Scheduler.JPG
Views:	53
Size:	60.1 KB
ID:	1356796

    Finally, I also added increased status value ranges and display icons to the SetPoint devices. They aren't strictly necessary so are applied to new VStats but existing VStats aren't updated automatically. You can update an Existing VStat by clicking the 'Rebuild' option on the Config page for that VStat. However, if you use different Mode Names for different VStats remember to set these in the Global Settings before clicking the 'Rebuild' button.

    Click image for larger version

Name:	SetPoint Icons.JPG
Views:	55
Size:	26.3 KB
ID:	1356797
    There probably won't be many users making use of these additional features but if you have any questions or spot any bugs please post here.

    Steve

  • #2
    Very nice indeed!

    Comment


    • #3
      Hi Steve

      I have been testing this a bit now and to me it seems to be working very nicely. Thank you so much for providing this value creating feature. I have now created almost all of my 15 zones and I am almost ready to switch over to use VSTAT in live-mode now... :-)

      I am not quite sure how the "Mode" work, if that one is marked for synchronizing. I believe the Mode is set by the scheduler, when going from one state to another. And of course if I set it manually. However, if the "Schedule" is not set for synchronizing from a master device, will the Mode then be set from the master device anyhow or only if the mode is set manually on the master (e.g. switching to holiday-mode)?

      Another thing which I noticed today is that it seems that VSTAT is setting device status (to on/off) by any change to the room temperature or when changing mode, despite the device may have the status set already (= no change). This sends out (a lot) of unnecessary traffic on the z-wave network. Why this?

      It is a very usable plug-in you created. Thanks again Steve...

      Comment


      • #4
        Originally posted by info@kaeseler.dk View Post
        Hi Steve

        I have been testing this a bit now and to me it seems to be working very nicely. Thank you so much for providing this value creating feature. I have now created almost all of my 15 zones and I am almost ready to switch over to use VSTAT in live-mode now... :-)

        I am not quite sure how the "Mode" work, if that one is marked for synchronizing. I believe the Mode is set by the scheduler, when going from one state to another. And of course if I set it manually. However, if the "Schedule" is not set for synchronizing from a master device, will the Mode then be set from the master device anyhow or only if the mode is set manually on the master (e.g. switching to holiday-mode)?
        The way a Slave works, if you sync the Mode with a Master, is that the Slave will still follow its own schedule when in Auto mode but will be controlled by any manual changes to the Mode of the Master. So whilst the Master and Slave are both on Auto the Slave will switch between Night and Day modes to its own 7 day schedule but if you switch a Master to Away/Frost any Slaves to that Master will also switch to Away/Frost. Switching the Master back to Auto will also switch the Slaves back to Auto. This allows you to turn Off a group of VStats in one go, when you perhaps go on holiday, and turn them all back to Auto when you return. Alternatively if you wanted the Slave to follow the automatic Mode changes of a Master you would sync the Schedules. I hope that makes sense.

        Originally posted by info@kaeseler.dk View Post
        Another thing which I noticed today is that it seems that VSTAT is setting device status (to on/off) by any change to the room temperature or when changing mode, despite the device may have the status set already (= no change). This sends out (a lot) of unnecessary traffic on the z-wave network. Why this?
        There is an option on the Config page to determine whether you want the VStats to behave in this manner.

        Click image for larger version

Name:	Force-Sync.JPG
Views:	49
Size:	16.5 KB
ID:	1363227

        If you deselect the option the pi should only send commands if it is a change.

        Personally I have this ticked because I configure the settings in my control devices (Fibaro and Qubino) to turn Off if they don't receive a command after a period of time. This is a fail safe which means that if HS3 was to go down for some reason the heating would turn off automatically after a set period of time Ticking ForceSync ensures that a command is sent at least every 15 minutes to prevent the control device automatically switching off.

        Steve

        Comment


        • #5
          This beta has been working fine for a while and nobody is reporting any problems so I will move it to general release.

          Steve

          Comment

          Working...
          X