Problems using mixed types of home automation hardware

A place to report bugs and discuss testing
Message
Author
dj-eon
Posts: 89
Joined: Wed Jul 13, 2011 4:03 am
Location: UK

Problems using mixed types of home automation hardware

#1 Post by dj-eon » Sun Feb 14, 2016 12:24 pm

Whilst developing my own Home Automation hardware, I came across a problem.

All my home made hardware works wireless on 434Mhz (310Mhz USA). However, so do my X10 PIR's

When the X10 devices send a code, they repeat it 5 times.
OSA normally responds the first of 5 codes and sends its response on another system that is also on the same radio band.

OSA is so quick that the code is transmitted whilst the X10 PIR is still transmitting. Both systems clash and the command is lost.
I found a workaround by just adding a delay in the plugin.

However I'm curious to know if anyone else has ever experienced anything like this?
Its obviously difficult to know its even happening unless you have radio receiver gear where you can hear what's happening.

Vaughn
Site Admin
Posts: 1432
Joined: Thu May 13, 2010 2:17 pm

Re: Problems using mixed types of home automation hardware

#2 Post by Vaughn » Sun Feb 14, 2016 1:34 pm

OSA does not respond to or retransmit any signals. Perhaps a plugin does, or hardware does. What hardware and plugin are you using that receives and retransmits (guessing probably a CM15A or CM17)?

I don't think any plugin should retransmit a wireless signal, only the protocols (like mess networks) should ever retransmit.

Well, let me know what plugin is doing this and I will take a look at it and/or publish your delay. If it is your CM17A doing it, I have never owned one of those to test the plugin, if that is the case, you are welcome to own or modify the CM17 plugin, else I will try to help.

User avatar
kherron
Posts: 639
Joined: Mon Dec 05, 2011 10:44 am
Location: Jacksonville, Fl.
Contact:

Re: Problems using mixed types of home automation hardware

#3 Post by kherron » Mon Feb 15, 2016 7:55 am

I feel that this is actually a conflict with your hardware devices and not actually with OSA.

I have an X-10 CM19A that uses the X-10 CM15A plugin.
The CM19A is a USB Wireless device only, so to get my commands to the power grid, I also have an X-10 TM751 RF Transceiver.
And in some cases it will cause a command to be sent twice, but I have never really had an issue as:
Sending: Front Porch Lights On twice, still only turns on the Front porch lights.

Is there not a way to specify a different channel, or change the frequency for your developed devices?
I would also think there would be a way to differentiate the data bits from an X-10 device and yours...
As Vaughn mentioned, there may be a way to change the plugin to know the difference.

Vaughn
Site Admin
Posts: 1432
Joined: Thu May 13, 2010 2:17 pm

Re: Problems using mixed types of home automation hardware

#4 Post by Vaughn » Mon Feb 15, 2016 2:35 pm

I think it is a collision issue, not an identity issue. This can happen with just X10. If you have 2 MS16A transmitting 5 times going off at the same time, the signals can get messed up. You do kinda have to design your setup to avoid issues like that. So a transmitting controller echoing what it receives would definitely cause issues. That's why I seldom seen it done. Maybe the CM17A has a good reason and the delay patch would work, but maybe it was just a bad choice in the plugin design to rebroadcast.

At worst it should be an option (Retransmit=TRUE/FALSE), the delay could also be a setting so people can refine their system.

Automate
Posts: 1691
Joined: Sat Dec 11, 2010 1:44 pm
Location: US

Re: Problems using mixed types of home automation hardware

#5 Post by Automate » Tue Feb 16, 2016 5:12 am

The CM17A hardware does not even support receiving X10 signals, only transmitting. So there is no way it could be re-transmitting a received X10 signal.

dj-eon
Posts: 89
Joined: Wed Jul 13, 2011 4:03 am
Location: UK

Re: Problems using mixed types of home automation hardware

#6 Post by dj-eon » Fri Feb 19, 2016 6:28 am

Sorry guys, I've probably chose the wrong words to describe the issue (although solved, I imagine it has come up with other hardware).

There is no problem with OSA or most folks plugins.

Let me set the scenario again.
An x10 PIR is triggered. It sends its RF code 5 times rather than once to be sure its successful. This is around 50 milliseconds x 5 = 250 mS

OSA gets the first code and reacts by sending a light on command 50mS later to a lightwaveRF device.
Both clash since X10 hasn't finished repeating its code, and now a lightwaveRF command is transmitting over the air on the same band.

I did solve this on my own hardware design by just sending the command again after 500 mS.

My question was only if anyone else had experienced this issue when writing plugins?

I easily managed to diagnose the issue since I have a radio that will tune to 433 Mhz, so it was obvious to hear what was happening.
But without this, it could have took a long time to diagnose.

Thanks for your time,
Ian.

User avatar
kherron
Posts: 639
Joined: Mon Dec 05, 2011 10:44 am
Location: Jacksonville, Fl.
Contact:

Re: Problems using mixed types of home automation hardware

#7 Post by kherron » Sun Feb 21, 2016 7:16 am

Ian,

I am sorry we may have come across a little defensive. But, please do not take it personal. ;)
As developers, we just want to solve your issues.

You did word it correctly:
When the X10 devices send a code, they repeat it 5 times.
OSA normally responds the first of 5 codes and sends its response on another system that is also on the same radio band.

OSA is so quick that the code is transmitted whilst the X10 PIR is still transmitting. Both systems clash and the command is lost.
I found a workaround by just adding a delay in the plugin.
Nowhere in there did you say OSA was Re-Transmitting the signal.
So we may have miss-read this, and kind-of jumped to a conclusion! Again, sorry for that! :(

I currently do not have any X-10 PIR's setup, as my CM19A does not support them.
However, I do have a script setup that turns ON/OFF my Front Porch and Back porch lights based on the Weather Day/Night events.
I have had occasions where the second device did not receive the command, because my CM19A was still sending the 1st command.
So the Back porch lights did not come on, even though the log and the state shows they did.
I was able to fix this by doing the same thing as you, by adding a delay between the commands.

As with all external hardware, it takes time for them to process and complete each task, so as a common procedure, I think all plugins should implement some type of delay after sending any information to a device. Even if it's only 50ms - 500ms.

Kirk

Vaughn
Site Admin
Posts: 1432
Joined: Thu May 13, 2010 2:17 pm

Re: Problems using mixed types of home automation hardware

#8 Post by Vaughn » Sun Feb 21, 2016 8:52 am

Yeah, I missed the "sends its response on another system" and assumed it was the same plugin, which would be bad. Did not think of 2 plugins using the same frequencies...

I just need to know where the delay was put in to make sure it makes it into the next update.

Vaughn

Vaughn
Site Admin
Posts: 1432
Joined: Thu May 13, 2010 2:17 pm

Re: Problems using mixed types of home automation hardware

#9 Post by Vaughn » Thu Mar 03, 2016 6:43 pm

So which plugin did you modify? Was it one under our source control? If so, I just released 048, but I would like to put the delay you tested in the current plugin so your don't have to worry about downloading new versions and have the issue come back and so other people won't have the issue either.

You can just paste the code here and line to insert at and I will handle putting it in Git, if you want.

Thanks!

Vaughn

User avatar
bwoodworth
Site Admin
Posts: 1563
Joined: Tue May 04, 2010 6:49 am
Location: California

Re: Problems using mixed types of home automation hardware

#10 Post by bwoodworth » Fri Mar 04, 2016 11:59 am

Does anyone else think that putting in a universal delay in a to sending commands not an ideal solution? Due to the way OSA manages events and sends out commands we already have a slight delay. Ideally in the situation where a motion sensor is tripped and the result is to send a command to turn on a light we would want that to be nearly instantaneous. Adding delays wouldn't be ideal. Of course collisions are even less ideal so maybe it is worth it, but I thought I would mention it.
Brian

Post Reply