Announcement

Collapse
No announcement yet.

Added c-bus to homeseer

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Added c-bus to homeseer

    Hi Folks

    Its early days, but I have c-bus controlling and being controlled by homeseer using Kevin Hawkins (ukusa) gateway via xap using the xap conduit plugin. I decided to try and get it working without the need for scripting for basic on / off / dim functions. I might not be using the plugin correctly and i certainly don't think i'm using its full potential but I will write a short guide on what i did to get c-bus working with homeseer, if any one is interested. In the mean time any questions or suggestions would be welcome.

    Regards
    Mark

    #2
    xap - C_bus

    Update re xap.

    I have switched to the mcsxap plugin due to some problems I had with xap conduit. The plugin would stop responding after about a day. I don't know if the problem is with the plugin or homeseer. mcsxap has been working for about 5 days so far with no problems. I may change to the .net version when i get more time.

    So far so good.


    Regards
    Mark

    Comment


      #3
      CBus - HomeSeer

      I'm a bloke from NZ and have CBus and HomeSeer and have considered getting Kevins hardware interface. I am very keen to get HomeSeer controlling my lighting but have no real scripting tools so am hoping to be able to do on off and dimming very simply as you mention and then hopefully integrate this with main lobby to have graphical sliders for dimming etc.
      Any help and advice you have would be much appreciated as I'm a bit lost on this project.

      Regards
      David

      Comment


        #4
        I to am intrested in how this all hangs together. Mark would it be possible for you to post a quick guide?
        I am just in the process of getting some C-BUS kit and while I have used homeseer with x10 and mainlobby for a while now ive not looked into XAP support.

        Something new to learn

        Thanks

        Stephen

        Comment


          #5
          Hi Stephen - replied offlist - but essentially just so others see how this works...

          C-Bus is a proprietary protocol and although a basic usage of the protocol is available under public release the full protocol requires joining the C-Bus Enabled program.

          The gateway, attaches to Ethernet and also directly onto C-Bus (not via C-Gate) and translates between the full C-Bus protocol and xAP which is a powerful open automation protocol. Being 'open' it allows other devices to fully interoperate in realtime with C-Bus.

          Now you install one of the three available xAP plugins for HomeSeer and you have individual devices that you can create that mirror C-Bus groups. They update and are controllable in realtime. At gateway power up the states of all these devices are synchronised to the matching C-Bus groups too.

          There are many other xAP standalone devices and PC applications too that further expand HomeSeer devices.

          Kevin

          Comment


            #6
            Dwarf3r

            I have an unfinished guide written, I will email it to you later today. I stopped the guide at the plugin section as i was having issues where the plugin would stop responding. I've switched to the mcsxap plugin and it has been working without a problem for some weeks now. When time permits I will finish the guide.

            Note: the guide doesn't go into too much technical depth. It just describes what I did to get all working .


            Regards
            Mark

            Comment


              #7
              Mark - I know you swapped from James' xAP plugin for HomeSeer to the mcs one and are having good results. What I would say is that I get dependable results from either but the mcs one has better visual feedback in HS web interface.

              HS has three 'properties' associated with each device but only one space in the web interface to display one of the values. These are ON|OFF, Level and a text string. Quite which it displays is very entwined. James' plugin does reliably update the values and trigger associated actions but HS may be displaying one of the values that didn't change at the time . This leads to an impression that it has stopped seeing changes when it hasn't.

              The two plugins are quite different in their design, configuration and some features, and the newer mcs one is written in .net so has some immediate advantages. It's a matter of personal choice, indeed you can run both although this is not recommended. The mcs one was designed to get xAP into a HS centric world and J's one gets HS into a xAP world . Just a different approach. I tend to find the mcs one more comforting for most users as they clearly see the updates as they happen but it's harder to integrate other HS devices back within xAP.

              Kevin
              Last edited by CouchPotatoe; October 27, 2007, 06:25 AM.

              Comment


                #8
                Version 2.2.0.7 of mcsXapNet allows all devices to be commanded via xapBSC except the X10 device codes. When these are commanded the xap-x10 schema is used.

                Comment


                  #9
                  Now that is a great update Michael - it really helps in the xAP 'distributed' methodology.

                  I am seeing great stability with your .Net plugin and it seems nicely fast. really pleased and now with this addition I would highly recommend people try it.

                  One Q. You exclude the X10 devices from BSC - was there a reason ? It would have been most useful to have them supported using BSC too , alongside the X10 schema, such that they can be integrated within a BSC environment as well, and controlled by some of the emerging BSC only controllers. More involved xAP devices often expose a BSC interface for maximum interoperability alongside a more appropriate , richer schema.

                  Kevin

                  Comment


                    #10
                    It was done this way because my x10 connector does not respond to xapbsc. What I did do was made the ability to inlcude the X10 devices in the BSC world conditional on the mcsXap setup checkbox setting for X10 Transmit. When not checked then X10 devices will be communicated via xapBSC if they have been Accepted for BSC transmission. V2.2.0.8.

                    Comment


                      #11
                      Well that's a quick workaround ... thanks Michael .

                      Some comments related to this and some other aspects...

                      Ideally I would like to be able to use the two schema (X10)/BSC) together though as I have both X10 and BSC clients to HomeSeer.

                      Played a little now and I'm finding that the subaddress is not changing between the BSC devices - permanently FFFE, and that's what shows in the web config page too.

                      uid=FF.000E:FFFE
                      class=xapbsc.event
                      source=mcs.Xap.VAIO:_SONOS_living_room_Track_Name.mcsXap____ __9017.Virtual

                      uid=FF.000E:FFFE
                      class=xapbsc.event
                      source=mcs.Xap.VAIO:_SONOS_living_room_Track_Duration.mcsXap ______9019.Virtual

                      [EDIT] I just updated to 2.2.0.8 and it seems this might already be fixed ... was it a change ?


                      Also seeing that the heartbeat and HomeSeer schema comes from a differently formatted UID. Would it be possible to take this up to :0000 rather than :00 -- they are both effectively equivalent - except that the heartbeat gives an indication of the possible address space used by the sub addresses. It's also revealed another buglette in Viewer in that they show as different devices...

                      uid=FF.000E:00
                      class=Homeseer.Event
                      source=mcs.Xap.VAIO

                      Let me think about the BSC presentation always as a Text device & using displaytext - I guess it may be the only easy and practical way to do it for all devices though.

                      Long sub address names too - does the 'mcsXap______' bit have a significance in your setup ? It's just taxing for the embedded devices as they have limited sub address storage space.. Indeed my gateway can't handle this - could it be removed ?

                      I wondered about including the originating device code somewhere in the message body or even sub address for easy cross reference - but it would have to adhere to the xAP allowable character set, which it might already do ... can you have dev codes with {} ?
                      [edit] Just realised that the number you use in the sub is a representation of the HS DC :-)

                      One other aspect - I am seeing that the displayed 'last updated' field is being updated by BSC.info messages , possibly this should only update if there actually is a change - ie an info that changed something (shouldn't happen) or a BSC.event. At startup a BSC.info might update an unknown/previous state I guess.

                      At startup it might be nice to 'query' the specific BSC endpoints that HS has devices for. ATM I use a wildcard BSC.query approach in a startup script which is rather brute force and tends to cause network floods. As my network grows it's getting worse - HomeVision for example can report nearly 1000 endpoints on a full device wildcard - although I only have half a dozen HomeVision devices created within HomeSeer. I suppose I could pull the in use xAP sourcenames names from the device DB.

                      Am I able to disable the HomeSeer.Event messages in any way, as there are a lot ? Perhaps another option in the 'optional xAP schema' section. For me anyway it's not needed on a per device basis.

                      I am seeing another issue (an old chestnut) but let me play a couple of more days and I'll contact you offlist if it persists.

                      Apologies to Mark for somewhat hijacking his thread.

                      Kevin
                      Last edited by CouchPotatoe; October 27, 2007, 07:11 AM.

                      Comment


                        #12
                        No worries about the hijacking Kevin.

                        I wasn't criticizing (sp?) James' plugin, however actions that previously caused changes and triggered actions just stopped working. I setup test actions based on xap triggers rather than relying on a visible state change in the HS web page. I didn't put much time into solving the problem, so it may have been something fixable. I ended up using Michael's old, non net plugin but I will try the net one again when I get time. Controlling my lights was my main goal, with C-bus and your gateway talking to homeseer, I have a reliable system, which could never be said for my X10 setup.



                        Regards
                        Mark

                        Comment


                          #13
                          I have been requesting a few additions to Michaels plugin recently - I'm sure he's well sick of me by now - but he's been really accommodating and the .Net plugin I think is now really good . It now interacts both ways nicely in a xAP system and is proving faster & really reliable now.

                          Although I think James' plugin is a cosmetically nicer with it's tabbed web interface and graphics, plus few extra bells and whistles I have to strongly recommend Michaels .Net xAP plugin nowadays. I am sure James will not be too upset - he doesn't use HS very much and is focussing on his own application (xAPFloorplan). He had to be somewhat horse whipped into writing it in the first place and I know debugging the OCX based version was a nightmare as it couldn't run in a debugger.

                          Kevin

                          Comment

                          Working...
                          X