Announcement

Collapse
No announcement yet.

How to get access to depreciated legacy properties

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

    How to get access to depreciated legacy properties

    I just started looking at migrating mcsSprinklers to HS4. mcsSprinklers was introduced to HS during the original HS days where the method of device identification was a variant of the X10 HouseCode-DeviceCode. While there was discussion about retaining the HS Code property, it seems it will be depreciated at time of HS4 release.

    When the HS3 .hsd file is imported there is no place in HS4 to hold the HS3 Code property so this information is lost. Since mcsSprinklers uses Code as its primary key for identification of a user setup it means that the user setup data will be lost. I recognize that a new means will be needed within mcsSprinklers for Code identification, but the problem is how to get the data during import or plugin initialization so the plugin can reconstruct the user information.

    Do provisions exists for getting access to HS3 device data from HS4 plugin? Is the author to do SQL queries of the HS3 .hsd file? Does a script need to be developed to run on HS3 that spits out the Code/Ref relationships of all devices?

    #2
    After you migrate the devices to an HS4 install, it would be interesting to see what tenScriptAid shows as far as what is in the Code field. It should run under HS4, but use the old HS3 access objects.
    tenholde

    Comment


      #3
      That does bring up another option to include the Scheduler.dll with the plugin to get access to the device properties. I suspect sometime in the future that HST will no longer have the backward compatibility so general use of Scheduler.dll methods would not be a good idea, but may be fine for the transition period.

      Comment


        #4
        Shodan I am wondering how your hs3 jeedom plugin would be affected by this?

        Thanks

        Comment


          #5
          Originally posted by Michael McSharry View Post
          That does bring up another option to include the Scheduler.dll with the plugin to get access to the device properties. I suspect sometime in the future that HST will no longer have the backward compatibility so general use of Scheduler.dll methods would not be a good idea, but may be fine for the transition period.
          It is unclear what the plan is for the scripting interface. It appears to still use IhsApplication.
          tenholde

          Comment


            #6
            Originally posted by MattL0 View Post
            Shodan I am wondering how your hs3 jeedom plugin would be affected by this?

            Thanks
            Hello MattL0,

            I warned HST since last october that this may impact my plugin.
            We had discussions but no real conclusion. I am too busy at work to spend time on the Jeedom plugin and on HS4 (especially when I see no benefit to move to HS4 for my own HA installation).
            After all, wasn’t HST claiming that HS3 plugins would remain compatible with HS4 ?


            Envoyé de mon iPhone en utilisant Tapatalk

            Comment


              #7
              Originally posted by Shodan View Post

              Hello MattL0,

              I warned HST since last october that this may impact my plugin.
              We had discussions but no real conclusion. I am too busy at work to spend time on the Jeedom plugin and on HS4 (especially when I see no benefit to move to HS4 for my own HA installation).
              After all, wasn’t HST claiming that HS3 plugins would remain compatible with HS4 ?


              Envoyé de mon iPhone en utilisant Tapatalk
              Totally with you. Thanks for the reply.

              In the worst scenario that hst do not listen. I might just install a copy of hs3 on the Jeedom server, and forward the values to hs via mqtt.
              Easy enough

              Comment

              Working...
              X