Ongoing development

[Kevin]

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

[TritonT]

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!

[Kevin]

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

[TritonT]

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.

[Kevin]

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

[erspearson]

I still maintain all my apps (hub, viewer) and the libraries xAPFramework (xFx) and xFx-Express. Not made any changes or updates recently as the technology is stable and mature.
Edward

[erspearson]

Just noticed the comment above about the source for X10. Happy to make that available.

[colski]

Just noticed this thread. I've been planning to spend some time on automating my home for a while, but other jobs like making it warm and water tight keep taking precedence! Anyway, my starting point will be the homeautomationhub link: http://www.homeautomationhub.com/ as it's support for room nodes looks to me to be a great start.