Extended Data Issue w/ Lynx 10 Plugin

[bsnedek]

Good Morning all,
I have never had any of the type of issues reported with the Lynx 10 PLC. However I am now experimenting w/ extended data transfers with no success. I seem to always get "Lynx 10 PLC - Plugin unsupported extended command recieved".
Can you tell me if this is from a malformed data stream or is extended data not supported by the plugin?

Thanks for your time
Brad Snedeker

[Rick Tinker]

The type of Marrick product that you have uses an X-10 TW523 or PSC05 as the primary X-10 interface. These devices cannot receive extended data commands, although they can transmit them.

You would need to change your X-10 interface to one that does NOT use one of these X-10 transceivers and you will eliminate that problem and be able to receive extended data commands.

[UniKyrn]

Rick, if he's using the PLC, he's got the all-in-one unit. It's the big LynX-10 board that needs the external interface, not the PLC that this plugin talks to.

And yes, I'm still waiting for you guys to fix that lockup bug.

[bsnedek]

Sorry Guys,
My Lynx 10 Plc plugs right into the wall outlet. Its their newest. According to Marrick's protocol it supports reception as well as transmission of all X-10 plus the new Marrick network protocols.
Here is my experiment. I have a PIC microcontroller hooked up to a Powerlinc II that is programmed to send an extended command with the analog data from a temp sensor. I am tring to change the status value of a device in Homeseer through a script. I can send standard standard X-10 commands this way. But recieve the error using the "Extended Data" X-10 command

Sorry about the confusion

[ericvic]

Brad,

I don't have the code in front of me but when I originally coded the plug-in it could handle most extended commands. I had some X-10 lamp modules that would send extended commands for status and it worked fine. I know there was some extended data that I thought was not implemented in any device that I didn't add support for so that must be what it is.

Eric

[bsnedek]

Thanks Eric,
Did you follow the standard format in your driver. I have seen several examples
HC,UC,Func,extend,extend....,ZD seems to be the most common. ZD being a byte of Zero data, and the first extend byte being byte count. This format seems to follow Homeseer and PowerLinc. But I can't seem to get beyound this error?

TIA

[bsnedek]

Good Morning All,
Since my last post I have been able to send Dim, Pre set Dim High, Pre set Dim Low, but still chocking on extended data. Using the Packet monitor that came with me Lynx 10 Plc I can see the recption of my extended data command. But still get the driver error in HomeSeer. ??

TIA

[bsnedek]

Well,
Couldn't seem to make the process work. To bad for the lack of support, or intrest not sure which. So I am going another route with RS-232. It seems to work just fine.

Not impressed...

If you build it they will come
If you support it they will stay

[UniKyrn]

It's a support more than interest issue, as best I can tell.

[firtha]

Brad, interesting that you're doing temperature sensors with extended commands.

I've been tinkering with temperature and humidity sensors using the pic micro for about a year now. Originally, I used preset dim, like the templinc and the HCS thermostats. However, once you get too many units transmitting, the unit codes stomp each other and you get misleading preset dims.

Ok, end of self-aggrandizing. (Edit: OK, not really, sorry)

A few weekends ago I decided to try the extended commands, since they at least have the housecode and unitcode in the same data chunk (unlike preset dim)... I'm still confused on the nomenclature, the commands seem to be called different things in different places. I tried the command that I believe you are trying, but since any info I got on it said that the first byte 'may' be a length, I thought that was optional, and couldn't see how a protocol would work if you 'may' follow it or 'may' not. In any case the 'Uncle' Phil Kingery article on the subject indicated that ACT repeaters (and presumably all others) could not repeat this command, since there was no way of telling its length.

However, in the same article was mentioned 'Extended code 1'. This seems to be a standard that is: housecode, command code, unit code, data byte 1, data byte 2, command byte 1, command byte 2.

The length is known so repeaters can repeat it. The data and command bytes can be essentially anything, as far as I can tell.

In another strange twist, I tried it the the Lynx-10 (yes, the PLC). I didn't get very far, the driver locked up, but in diagnostic mode it works fine. (In fairness, I have to say that I'm trying to use the Lynx-10 through a USB to serial adapter, which I've found 'mostly' works. So it could be the adapter this time)

I tried the Lynx-10 because I normally use the Powerlinc USB, but its diagnostic utility sometimes looks 'strange', and besides, you have to decode a long bit string. The powerlinc USB will sometime receive corrupted packets that the Lynx-10 says are fine.

This post is a very long way of saying 'me too', but I thought I would share my experiences. If anyone has any thoughts on what the powerlinc is doing, or has tried extended codes on it, I'd like to hear their experiences.

Attached below is a capture of the Lynx-10 diagnostic window. I send a status request to my module, and it replies with data 0x18, which corresponds to 24 deg C. I force the 'Cmd' to zero, and test for that in my decode script, since the powerlinc will usually stuff some random non zero number here when it goofs a packet.

[bsnedek]

Firtha,
First let me say WOW, I'm not alone, this is way to cool. I have lots of experences from capturing X-10 both in the RF format and the standard power line format. The main thing that determines the end of an X-10 packet is 3 pauses in the data stream IE. "000" This holds true in the RF and normal X-10 protocols. Extended Data is like a Dim Function, the data is a constant stream until "000" These are of course 3 bytes not bits.
You are very correct. PowerLincs utility is very hard to decode. I built an X-10 line monitor using a pic and 2 line LCD display. It was very limited in that it used the TW-523. Then when I found the POwerlinc II Serial I rebuilt the monitor, and cool. it shows it all. Just one hassel with decoding the HEX back into X-10 but way easier than the ASCII that PowerLinc Utility shows.
How can we contact each other?

[firtha]

I forgot to mention that I also have a testerlinc. It complains about all my extended commands, bad start codes, bad blocks, etc. So I have three X10 monitors: The testerlinc, the 'USB powerlinc synapse', and the Lynx-10. All three disagree on what a 'correct' packet is.

My email is in my profile, if you wish to drop a line...

[bsnedek]

Firtha,
I tried to email you yesterday and this morning. I seem to be getting a error 550

Your message cannot be delivered to the following recipients:

Recipient address: hsfan@SPAMLESSshaw.ca
Reason: Illegal host/domain name found

Mine is bsnedek@direcway.com

[Rick Tinker]

Remove SPAMLESS from the email address and I am sure it will work.

[firtha]

I figure the 'bots will have figured out 'nospam' by now...