Announcement

Collapse
No announcement yet.

Receiving X10 from Plugin or HS3

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

  • Receiving X10 from Plugin or HS3

    I am working on a plugin for the RCS X10 TX15 and TX16 thermostats. I know its unthinkable but its all that is standing between me and HS3. I have four TXB16s running between my house and my business and they have been solid for many years. I am trying to figure out how my plugin can be notified when an X10 signal is received by HomeSeer. Using RegisterEventCB I can get the X10 if I manually create a device in the UI and set the address in the "X10" tab. This results in a device owned by the X10 plugin. Trouble is I need my plugin to own the devices it creates. Is there a way to get callbacks from another plugin? Can the X10 plugin or HomeSeer notify my plugin that X10 has been received? Is there a way for me to create "catch all" device in HomeSeer that will raise an event on all X10 received or at least one entire house code?

    Thanks

  • #2
    Registering for value change callback should register for every device in a HS system irrespective of the originating plugin - you then decide in the HSEvent function what you want to do with the information and how you wish to process it.

    HOWEVER I do wonder whether or not it will actually give you what you want with the status of the X10 plugin and HS3, are you getting anything that looks sensible in your devices when you are firing off events on the thermostat?

    I think I looked at these thermostats for someone when I wrote a .net compliant TI103 plugin (probably five/six years ago I would say) and they drove me a little crazy trying to get them to work (which I failed at ultimately), if I remember right was the data converted into a format broken down and sent in sections over a period of time?
    My Plugins:

    Pushover 3P | DoorBird 3P | Current Cost 3P | Velleman K8055 3P | LAMetric 3P | Garadget 3P | Hive 3P |
    Yeelight 3P | Nanoleaf 3P

    Comment


    • #3
      I have gotten that part but I have two obstacles. I can create devices from my plugin and assign housecodes/unitcodes to them. But they don't seem to update or trigger an HSEvent when an X10 command comes in that matches the codes assigned to the device I created. I assume this is because the device is owned by my plugin, not the X10 plugin. Alternatively, if I create the devices in the UI they are then owned by the X10 plugin, not my plugin. I don't know yet if that is truly a problem. The devices respond to X10 commands and trigger HSEvents in my plugin. My problem then becomes I cannot automate the creation of all the devices (fan mode, operating mode, setpoint, etc) needed to control the thermostat from my plugin. So (I think) I need to overcome one of these problems- either be able to create a device from my plugin that responds to incoming X10 or create an X10-owned device from my plugin.

      It's also quite possible I don't know what I am doing. Without the demo projects and trolling the forums I don't know that I could do anything. The world seems to have largely given up on X10 so I don't have much to go on. Perhaps I have taken the wrong approach.

      Regarding the thermostats themselves: yes, they are tricky to say the least. When there are changes at the unit it sometimes results in multiple X10 commands coming in. When echo and ack modes are enabled on the Tstats you get different X10 codes sent back from the units when you send a command. It creates a lot of traffic. I fully expect a variety of timing issues... or I'll give up and buy some z wave stats.

      Comment


      • #4
        Yes... I also had a TXB16 T-stat when I was using HS2. It pretty much ran flawless from 2005 to just this past March with Jim Doolittle's doostat plugin when I finally moved to HS3. This too was holding me back... I settled for a Trane Z-wave XL624 stat as I didn't want to wait for someone to come up to the plate like you to create the X-10 stat plugin. I think it was the wiser choice. Also Jim's plugin wouldn't integrate into HSTouch properly. So all in all, I'm happy now...
        I think it might not be worth creating a plugin to those stats - personal opinion of course. Unless of course, you have free time and are looking for a challenge.

        BTW, I have an extra XL624 stat (new and unused) up for grabs..

        Robert
        HS3PRO 3.0.0.500 as a Fire Daemon service, Windows 2016 Server Std Intel Core i5 PC HTPC Slim SFF 4GB, 120GB SSD drive, WLG800, RFXCom, TI103,NetCam, UltraNetcam3, BLBackup, CurrentCost 3P Rain8Net, MCsSprinker, HSTouch, Ademco Security plugin/AD2USB, JowiHue, various Oregon Scientific temp/humidity sensors, Z-Net, Zsmoke, Aeron Labs micro switches, Amazon Echo Dots, WS+, WD+ ... on and on.

        Comment


        • #5
          Originally posted by steve6341 View Post
          I am working on a plugin for the RCS X10 TX15 and TX16 thermostats. I know its unthinkable but its all that is standing between me and HS3. I have four TXB16s running between my house and my business and they have been solid for many years.
          If you are doing this for the 'entertainment' value and the challenge, then I commend your initiative, but replacing the thermostats seems like a much easier and less expensive option.

          Edit: Robert, you beat me to the punch!
          Mike____________________________________________________________ __________________
          HS3 Pro Edition 3.0.0.500

          HW: Stargate | NX8e | CAV6.6 | Squeezebox | PCS | WGL 800RF, Rain8Net+ | RFXCOM | QSE100D | Vantage Pro | Green-Eye | X10: XTB-232, -IIR | Edgeport/8 | Way2Call | Ecobee3

          Comment


          • #6
            Originally posted by steve6341 View Post
            I have gotten that part but I have two obstacles. I can create devices from my plugin and assign housecodes/unitcodes to them. But they don't seem to update or trigger an HSEvent when an X10 command comes in that matches the codes assigned to the device I created. I assume this is because the device is owned by my plugin, not the X10 plugin. Alternatively, if I create the devices in the UI they are then owned by the X10 plugin, not my plugin. I don't know yet if that is truly a problem. The devices respond to X10 commands and trigger HSEvents in my plugin. My problem then becomes I cannot automate the creation of all the devices (fan mode, operating mode, setpoint, etc) needed to control the thermostat from my plugin. So (I think) I need to overcome one of these problems- either be able to create a device from my plugin that responds to incoming X10 or create an X10-owned device from my plugin.

            It's also quite possible I don't know what I am doing. Without the demo projects and trolling the forums I don't know that I could do anything. The world seems to have largely given up on X10 so I don't have much to go on. Perhaps I have taken the wrong approach.

            Regarding the thermostats themselves: yes, they are tricky to say the least. When there are changes at the unit it sometimes results in multiple X10 commands coming in. When echo and ack modes are enabled on the Tstats you get different X10 codes sent back from the units when you send a command. It creates a lot of traffic. I fully expect a variety of timing issues... or I'll give up and buy some z wave stats.
            It ain't going to be possible without some hard work to create a device by code in your plugin because the format of what makes that particular device respond to that code in the X10 plugin and the device type is encoded in a custom object type in the device extra data store. I have just converted the byte array to a string and this is what it shows;

            Code:
            	????@HSPI_X10, Version=3.0.0.36, Culture=neutral, PublicKeyToken=null%HSPI_X10.Classes+X10ConfigurationDataiRef	sInstance sHouseCode sUnitCodeiLastCommand iDimValueiDimPctiValuebEnablediDeviceTypeiDimTypeiData1iData2HoldSliderValueSliderValue IFaceNameeA3d?
            Clearly there is some sort of data type being kept in there (would be a very odd method to store the data like that) that only the developers will know about and I'm not sure you will get an answer unfortunately. It is things like this that were simple in HS2
            My Plugins:

            Pushover 3P | DoorBird 3P | Current Cost 3P | Velleman K8055 3P | LAMetric 3P | Garadget 3P | Hive 3P |
            Yeelight 3P | Nanoleaf 3P

            Comment


            • #7
              I don't know if this will help anyone else (or if it even helps me yet) but a device can made to respond to incoming X10 by using the set_Interface method. Something similar to the following:

              Code:
              DeviceClass dc = (DeviceClass)hs.GetDeviceByRef(dvRef);
              dc.set_Interface(hs, "X10");

              Comment

              Working...
              X