Ongoing development

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • TritonT
    Automated Home Lurker
    • Sep 2012
    • 4

    Ongoing development

    I'd like to request a 'state-of-play' for xAP. Is anyone actively developing any Connectors? Is anyone apart from Michael McSharry updating any existing Connectors or Applications?

    The reason I ask, is that I would like to add an RFXtrx433 to my setup. This would let me dump most of my X10 kit as well as being able to easily add weather/smoke detection/blind control/curtain control/ gate control without adding more cables.

    I have been running xAP for more than 9 years and have done a few installs for clients as well as my own network. Overall it has been great. I feel bad that I don't have the time/skills to help develop Connectors or maintain the existing Hubs, Connectors and Applications. I would like to know if now would be a sensible time to jump ship to something with a more active development community.

    Picking an alternative isn't going to be easy, my current setup is:

    xAP Floorplan (all my scripted events, web interface - stable)
    xAP Netiom (window sensors, door sensors, door bell, relays - rock stable)
    xAP X10 GUI (lights, sockets, remotes - stable)
    xAP mcsK3145 (temperature sensors - unstable)
    xAP mcs1Wire (temperature sensors, iButton door entry - unstable)
    xAP mscCID (Caller ID - stable)
    xAP Jabber (messaging - unstable)
    xAP Weather (local weather - stable)

    I have been involved in a number of Open Source projects over the years and I understand that interest and available time can wane, so I'm just trying to find out if anyone was interested in finding a way to get a couple of new Connectors done.
  • bigkevmcd
    Automated Home Lurker
    • Aug 2012
    • 4

    #2
    I'm not sure about the state of play for xAP, it looks pretty much dead to me, but I'm an outsider, so there may well be a lot of ongoing development that's hidden to me.

    I can say that working with the rfxtrx433 is great, the interface is nice to work with, and I have a Node.js JavaScript app undergoing development, of which the rfxcom library is an offshoot, currently, it only handles a subset of the possible rfxtrx433 devices, but adding more should be trivial (the test infrastructure is hopefully good enough to make that trivial).

    If you're interested, https://npmjs.org/package/rfxcom

    I'm happy to answer questions / fix bugs / add new features :-)

    Even if Node.js isn't your bag, the rfxtrx433 is great to work with and I can recommend it.

    Comment

    • Kevin
      Moderator
      • Jan 2004
      • 558

      #3
      TritonT,

      Welcome - first post I see, and in a way there in a nutshell is why we are where we are. I know there are a lot of lurkers that use xAP extensively but don't contribute back to the project either because they don't have the time or skills to do so. But there's lot's of documentation, how to's, 'my setup' stories that would help too.

      xAP is pretty mature now with v1.3 and is not in need of any basic protocol refinement. It does what it says on the tin and is still AFAIK the only solution positioned to be simple, expandable and accessible to everyone with basic programming/scripting skills. BTW I encompass xPL in this too. It allows hobbyist level upward users to achieve home automation across all their disparate devices. Unless anyone can suggest another viable alternative with these credentials ?

      What it hasn't achieved though is the snowball of users contributing their own conduits and applications for the specific devices they own. I know people do still write these but they are often never published due to being feature incomplete, hardcoded to the originators system, or because suitable documentation and support time is not available. Most of the existing applications have come from the real enthusiasts supporting their personal devices and systems. They don't own or have a vested interest to include the other devices people request. That said the base of xAP applications and devices is pretty extensive.

      The RFXtrx433 exactly illustrates this issue. Both xAP and xPL have conduits for the previous RFXCOM hardware and those have taken much investement of time and support but even when seemingly complete these applications now demand further maintainance as new hardware is released. The original authors don't have that new hardware, the time or any real incentive to support it as their own system is working fine. As there are no $$ involved xAP has that dichotomy of time / reward.

      I hear the RFXtrx433 is a great product but I personally don't own one . I do keep looking at it though and have seriously considered purchasing one but actually, if I'm honest, even if I did and wrote a xAP conduit for it I am not sure I would publish it as the time and support obligation would be too much for me currently. I too would really like to see a xAP conduit available :-)

      I still use xAP extensively and I plan on doing so for the forseeable future as it is the only solution I know of that enables me, as a hobbyist level developer, to integrate anything and everything I own. Yes, I would love there to be vast libraries of conduits and applications appearing daily but I also accept that isn't going to happen and development here is pretty dormant. I myself keep adding xAP conduits as I forage new gadgets but these will likely never be available generally due to time and support issues. Been there, done that.

      So for me xAP is still the solution . I do not know of any real alternative but I would love there to be something offering a vast device library , manufacturer agnostic and accessible to hobbyist level coders. I have bitten the bullet a little in my AV implementation allowing Crestron into my system, but only after it was tamed with a xAP module too. You do get huge libraries with Crestron but you pay $$ too.

      Kevin
      Last edited by Kevin; 11 October 2012, 09:08 PM.

      Comment

      • Kevin
        Moderator
        • Jan 2004
        • 558

        #4
        Originally posted by TritonT View Post
        xAP mcsK3145 (temperature sensors - unstable)
        xAP mcs1Wire (temperature sensors, iButton door entry - unstable)
        It's interesting - I get more comment about xAP issues with these mcs 1-wire apps than anything else. It's a shame as it's nothing to do with xAP but usually the vagueries of 1-wire networks, or possibly that conduit I'm not sure.

        In recognition of this Daniel Berenguer made the OPNOne - a totally embedded 1-wire xAP solution with many different devices supported. Works brilliantly and rock solid but it had an associated cost of around $100 which was deemed too expensive and so after the first or second batch it was discontinued. There are of course some other embedded 1-wire controllers that can talk xAP but none as flexible or low cost as that.

        K

        Comment

        • Kevin
          Moderator
          • Jan 2004
          • 558

          #5
          Triton,

          Just a thought. I'm guessing you're a HomeSeer user and RFXCOM sell a plugin for that. Does that not support the new rfxtxr433 ? As the manufacturer they have the incentive to do that. If so then you essentially already have a xAP enabled rfxtxr433 by using the mcs XAP HomeSeer plugin. Any HS device can be exposed on xAP this way.

          K

          Comment

          • bigkevmcd
            Automated Home Lurker
            • Aug 2012
            • 4

            #6
            Ok, I've spent a couple of hours knocking out a quick xAP broadcaster in Node.js, it's not quite finished, as I need to get it sending to the correct broadcast address, but am on it.

            The plan is that you will be able to do something like this...

            Code:
            var rfxcom = require('rfxcom'),
                 xap = require('xap'),
                 rfxtrx = new rfxcom.RfxCom('/dev/ttyUSB0'),
                 transmitter = new xap.XAPTransmitter(
                    {class: 'Thermostat.status', source: 'rfxcom.WMR800.external', uid: 'FF000001'});
             
            rfxtrx.on('th3', function (evt) {
              transmitter.send('temp.current', {'temp': evt.temperature, 'units': 'C'});
              // could log it to Cosm, or do something else here...
            });
            
            rfxtrx.initialise();
            I'll hopefully get the last couple of issues ironed out over the weekend and make an initial release, but I have the message generation working, and transmitting, just need to see if I can determine the broadcast address automatically...

            Comment

            • bigkevmcd
              Automated Home Lurker
              • Aug 2012
              • 4

              #7
              Work in progress released.

              Ok, I've released 0.0.1.

              I'm not a fan of xAP, this is just a proof of concept, I'm working on a parser for xAP messages, but I thought I'd get this out there...

              The rfxcom library will currently report data from Oregon Scientific devices, and OWL electricity monitors, but it's fairly trivial to add support for anything that the rfxtrx433 supports.

              I've tested this on a Raspberry Pi hooked up to the Rfxtrx433 with this code...

              Code:
              var RfxCom = require('rfxcom').RfxCom,
                  xap = require('xap'),
                  rfxcom = new RfxCom("/dev/ttyUSB0", {debug: true}),
                  transmitter = new xap.XAPTransmitter(
                    {class: 'Thermostat.status', source: 'rfxcom.WMR800.external', uid: 'FF123400'});
              
              rfxcom.on("th3", function(evt) {
                transmitter.send('temp.current', {'temp': evt.temperature, 'units': 'C'});
              });
              
              rfxcom.initialise();
              And looked at the packets being transmitted in Wireshark, it seems fine, I'm looking for a simple xAP app to report the messages, but it's unlikely I'd build on top of xAP (I'm not a fan of UDP, and I can't see a benefit of a message format that is more work to parse than JSON).

              But if this is of use to anybody, feel free, and if it doesn't work, I will fix any reported bugs.

              Oh, and it'd be useful if I provided a link, https://github.com/bigkevmcd/node-xap

              Comment

              • Kevin
                Moderator
                • Jan 2004
                • 558

                #8
                Interesting Kevin.. thanks for this.. I wish I had a rftxrx433 to try it out.. tempted again now...

                xFX Viewer is the standard listener app. (.NET) but that may not be appropriate for you. What xAP schema are you using ? Happy to help on the xAP compliance side if you need anything..


                UDP was chosen at the time to enforce a simple broadcast mechanism with low overhead and to deliberately defeat private point to point communication. There are other solutions of course. You can use xAP over TCP into the xServer or iServer application which were primarily intended for WAN linking of xAP networks. iServer is embedded in several devices and there may even be a Raspberry PI flavour - or certainly source code. The iServer has an added advantage of implementing on the fly filtering to rminimise traffic to less capable devices if needed.

                A little while ago it was suggested to look at enhancing xAP with JSON but the original proposer didn't follow this through. It's an interesting possibility though and I would welcome anyone taking on this..

                ISTR there was also talk of porting the whole HAH project from the LiveBox to Raspberry PI



                Cheers Kevin

                Comment

                • Kevin
                  Moderator
                  • Jan 2004
                  • 558

                  #9
                  Originally posted by Kevin View Post
                  I myself keep adding xAP conduits as I forage new gadgets but these will likely never be available generally due to time and support issues.
                  One thing I have done a lot of work with is a native iOS (iPad / iPhone / iPod) touch screen control application that is fully customisable and supports xAP directly either via UDP or iServer (TCP) the latter being recommended because of potential WiFi issues. This is xAP integration within an existing ($15) commercial application. The additional xAP support is at no cost. It hasn't been released yet but could be available for beta testing as it is very nearly complete. If anyone is interested let me know as it's something that I do want to get out there.

                  Kevin

                  Comment

                  • TritonT
                    Automated Home Lurker
                    • Sep 2012
                    • 4

                    #10
                    @ Kevin

                    Different people will have different theories as to why a particular project does not become dominant in it's area. In the case of xAP I think a couple of things that haven't helped are; not communicating in a centralised forum and not having a centralised open code repository under SVN or Git.

                    You must find it infuriating (I know I do) that other projects have come along and 'reinvented the wheel' instead of building on xAP. DomotiGa and OpenSourceAutomation have made amazing progress and have support for more devices than xAP does, however, architecturally xAP makes much more sense to me.

                    A few years ago my primary control method was MediaPortal, secondary Jabber/XMPP and occasionally Floorplan's web interface. Now the MediaPoral plugin is obsolete and xAP Jabber doesn't work reliably (can't pin down why) so I've just got Floorplan left.

                    As an aside the MediaPortal plugin was brilliant, it allowed me to control everything from any of the house TVs in a unified interface. It even had screen popping of events like incoming calls, washing machine finishing etc. using and slightly extended version of message.display. Luckily all the code is available, so I may pay someone to put it back together, might only take a couple of hours.

                    Cost of equipment is not much of an issue for me anymore, but I try to only buy equipment and services with an open API. That way there is always a chance that someone will code for it. Personally I'm in favour of open sourcing code onto the internet when it is no longer going to be updated or I can't face supporting it, however I realise that there are many reasons others don't want to do that.

                    Comment

                    • Kevin
                      Moderator
                      • Jan 2004
                      • 558

                      #11
                      Originally posted by TritonT View Post
                      I would like to add an RFXtrx433 to my setup. This would let me dump most of my X10 kit as well as being able to easily add weather/smoke detection/blind control/curtain control/ gate control without adding more cables.
                      Are there definite devices that you need to add here and defined schema that you would like them to use ? I ask because X10 for example had a couple of schema and there are some others that don't have specific schema available e.g. blinds, curtains etc. It may well be that you will need/want to be able to adapt a xAP application for the RFXtxrx to your own devices anyway rather than having some shoehorned BSC implementation or would a general schema that reported whole messages and allowed you to build and send them be appropriate ? Rather like the RFXmanager does.... the dropdown fields being settable via a xAP message ? The latter would seem very easy to knock up a quick application for.

                      0B110001031935F403010F70
                      Packettype = Lighting2
                      subtype = AC
                      Sequence nbr = 1
                      ID = 31935F4
                      Unit = 3
                      Command = On
                      Signal level = 7

                      Lighting2 command:0B 11 00 0B 03 19 35 F4 03 00 0F 00
                      ------------------------------------------------
                      0402010B00
                      Packettype = Receiver/Transmitter Message
                      subtype = Transmitter Response
                      Sequence nbr = 11
                      response = ACK, data correct transmitted
                      ------------------------------------------------

                      Or is bigkevmcd's approach useful to you ?

                      K

                      Comment

                      • TritonT
                        Automated Home Lurker
                        • Sep 2012
                        • 4

                        #12
                        I have started testing the RFXtrx433. So far I have range tested it with X10 (TM13 trannsceiver, HR10E/HR12U remote), Bye Bye Standby (BBSB300 socket dimmer) and Byron (RS61 ceiling switch, RS63 ceiling dimmer, RS15 switch). Results are pretty good, it would seem that it is reliable in a small to medium sized house as long as the RFXtrx433 is positioned fairly centrally.

                        Over the next week I will be testing smoke alarms (Profitec Funk Rauchmelder KD 101 LA) and weather sensors (Oregon Scientific THN132N, Oregon Scientific THGN132N).

                        Regarding schema, most of the nodes a RFXtrx433 can add are covered by the BSC schema and Weather schema. I have no idea yet how to deal with blinds etc. however I am working my way through the list of supported devices to see if anything stands out as requiring something new.

                        I have a spare Raspberry Pi sitting here so I am also going to test DomotiGa with RFXtrx433, once I am happy that the RFXtrx433 works on Pi with no issues I will have a look at bigkevmcd’s code. For purely selfish reasons at the minute I just want xAP to work with the largest number or devices and services possible, with the very least effort from any developer. There are many good arguments for structural and transport changes in xAP, but as there is nobody to take on this amount of coding it’s a bit moot.

                        My idea for significantly extending the functionality of xAP is to create 2 new Connectors. Firstly a semi generic serial device Connector for a range of devices not just the RFXtrx433. Secondly, a Connector for sending and receiving HTTP and UDP messages. I'll create a thread for each to explain what I’m on about and for people with more knowledge than me to say whether it's feasible or even a good idea!

                        Comment

                        • Kevin
                          Moderator
                          • Jan 2004
                          • 558

                          #13
                          I got a small package in the post this week too ;-) I generally avoid using devices in my home that don't acknowledge control requests or return status, especially for local control. X10 went a while back but I do still have some HomeEasy RF sockets and switches, and weather data. My PIR's are on 868Mhz though. I'm tempted by an RF based heating control system / TRV's although again 868Mhz but I gather that'll be available soon. So I'm interested in this project.

                          BSC is a great schema and although simple in appearance it is quite tricky to implement due to it's bidirectional nature. Because it is our xAP 'plug and play' offering we try and ensure it rigerously and completely implements the published spec. which makes for a much better experience for everyone.

                          BSC does provide a general serial device driver supporting binary data , although it's not very efficient because it has to encode binary data as ascii hex. Useful for small message exchanges though, the Phaedrus Netiom implements this. Any Q's you might have on BSC just ask away and I'll do my best to help.

                          Curiously when your post arrived I too was perusing the DomotiGa site and staring at a Raspberry Pi sitting on my desk. I have no Linux expertise but I may try and get it running. It would be nice to progress their feature request 163 as well... is that something you might be up for ?

                          K

                          Comment

                          • TritonT
                            Automated Home Lurker
                            • Sep 2012
                            • 4

                            #14
                            I appreciate that for BSC to be properly implemented it requires state response which is not available on the majority of devices that the RFXtrx433 can (or will in the future) interact with. However I have used the ERSP X10 Connector for many years and it uses BSC, with the state response being best described as faked!

                            If only the source for the ERSP X10 Connector was available, it would have been a quicker and easier process to get a working RFXtrx433 Connector.

                            I have been looking for 433MHz battery TRVs as well, with no success. I probably won’t get around to trying the LightwaveRF ones as from what I’ve read the LightwaveRF kit may interfere with my Oregon Scientific stuff. I could bring my 24V relay-controlled TRVs under wireless control but there would be no benefit as I would still have trailing wires.

                            I’ve tested a Profitec Funk Rauchmelder KD 101 LA smoke alarm, works perfectly. It going to be a long time before I get bored being able to switch on a smoke alarm to get the kids out of bed!

                            I have a working DomotiGa on Raspberry Pi, but no time yet to try the RFXtrx433. A fulfilled feature request 163 solves my setup, but doesn’t make xAP any more relevant, it kinda makes things worse. DomotiGa already supports the vast majority of devices that xAP does, adding a plugin just helps people transition away from xAP. I’d miss Floorplan.

                            Comment

                            • Kevin
                              Moderator
                              • Jan 2004
                              • 558

                              #15
                              I think the important thing is that the BSC schema is properly implemented as I have seen it being used in a single directional implementation or worse still providing a periodic status response but not responding to xAPBSC.cmd or xAPBSC.query messages or handling wildcarded target addresses. This can paradoxically confuse the more 'intelligent' controllers into sending repeated requests as they believe the device hasn't actioned the command. The fact that staus responses are 'faked' or 'assumed' is not so much of a concern as an implementation limitation that the user elects to accept in for example 1-way devices like x10 , Infrared, RF etc.

                              Did you ask Edward about availability of the ERSP X10 code - given he is unlikley to be onwardly developing / supporting it he may well be happy to release it ?

                              One of the interesting aspects of xAP is that it makes devices networkable , i.e. independent of their host PC and application.. shareable by everything. Devices supported within Domotiga or indeed any other application either directly or through plugins do not achieve this. They typically become owned and dedicated to the parent application. Having xAP support within these applications allows all these directly supported devices to be exposed on xAP and hence accessible to other xAP aware applications. So if say you used HomeSeer, Cortex and Domotiga (+FR#163) you could share the devices supported in any application between them all.

                              You can build a truly distributed architecture with multiple controllers ... one to many, many to one or indeed many to many. You could even run parallel / redundant controllers for failsafe if you wish. This would allow you for example to continue to use xAP Floorplan alongside Domotiga (+FR#163). There are also no point to point TCP socket bindings that so often cause stall and lockup issues later should you retire Floorplan or any other xAP controller / device.

                              I look at xAP currently as a methodology and a facilitator - providing a common ground that all the devices can share - rather like a board room table discussion in Esperanto. Whilst many devices talk directly to each other outside of xAP e.g. my switches to my lights they also chat on xAP. It provides me a way of ensuring everthing that happens in my home is accessible and open so that I can add and remove bits as I wish, avoiding being locked in to an application/device. For me this has been the most significant benefit of xAP and why I shall continue to use it going forward - until something else comes along that is better and can replace it ..... of course other peoples mileage may vary as they have different needs.

                              K
                              Last edited by Kevin; 26 October 2012, 05:41 PM.

                              Comment

                              Working...
                              X