Sending raw data

Functionality and usage of the OpenNethome Server
perjarle
Posts: 32
Joined: Wed Aug 03, 2016 8:08 am

Sending raw data

Post by perjarle » Tue Sep 20, 2016 12:04 pm

Hello
Is there any existing controls that can send raw data out through the Tellstick?

One thing that would be great to have would be a RawDataMQTTSwitch that can receive a hex string through mqtt and just send it out through the tellstick

This would open up for a lot of DIY posibillities

/PJ

stefangsbb
Site Admin
Posts: 311
Joined: Sun Nov 30, 2014 2:16 pm

Re: Sending raw data

Post by stefangsbb » Tue Sep 20, 2016 8:16 pm

Hi PJ,

It depends a bit on what you mean with sending a hex string to it. Tellstick has a binary protocol which is used to communicate with it. Over that protocol you can instruct the Tellstick to send messages over a number of protocols, and it can report received messages for protocols it knows.

When it comes to sending messages this binary protocol also supports sending raw pulses, just specifying mark and space lengths of the pulses and this is the interface that OpenNetHome uses. This means that OpenNetHome bypasses Tellstick's protocol encoders and uses its own encoders instead, just sending raw pulse trains to Tellstick. I am guessing this is the kind of access you are talking about. The binary protocol is kind of tricky to use and has some rather strict limitations regarding how long the messages can be and so on.

OpenNetHome does not directly expose this interface, but indirectly it does! Among the protocols OpenNetHome supports, ProntoCodes is one of them. ProntoCodes is a protoocol used by self learning remote controls and just stores sampled remote control codes as a list of pulse lengths. This means that you can take any raw pulse message, format it as a proper Pronto-message and send it as a Pronto_Message-event to OpenNetHome and it will pass that on to Tellstick which will send the raw pulses.

One thing to keep in mind here is that when it comes to the 433MHz protocols, it is a bit of Wild West style. All protocols use different ways of encoding bits and bit order, so when sending data, you cannot just send a hex message, you have to know which protocol to send it with and how that protocol encodes the bits and in what order. So what you end up sending on the low level is a list of pulse lengths and then you have to figure out which pulse lengths are used to form "0" and "1" in the protocol you are using. This is what the protocol encoders in OpenNetHome does.

SourceCodeSourcerer
Posts: 10
Joined: Mon Mar 02, 2015 9:58 pm

Re: Sending raw data

Post by SourceCodeSourcerer » Tue Sep 20, 2016 9:19 pm

+1 for the excellent explanation, Stefan!

perjarle
Posts: 32
Joined: Wed Aug 03, 2016 8:08 am

Re: Sending raw data

Post by perjarle » Mon Sep 26, 2016 1:55 pm

Thank you for detailed explanation Stefan
- And sorry for my slow response.

As you can guess I'm quite a newbie when it comes to protocols and wireless.

Do you happen to have an example sketch for Arduino that receive and decode pronto-codes which are sent from ONH?

I went into the Create/Edit page and tried to create a ProntoDevice but was confused what to type in.
What is the format for the different commands/commandcodes? is it binary strings?

/PJ

stefangsbb
Site Admin
Posts: 311
Joined: Sun Nov 30, 2014 2:16 pm

Re: Sending raw data

Post by stefangsbb » Mon Sep 26, 2016 6:44 pm

You don't want to sample the Pronto codes from OpenNethome, there you already have the source code that describes how the protocols work.

The pronto format is a HEX code based format originally used to describe signals from IR-Remote Controls. The protocols used on the 433MHz band are very similar (I think they use the same circuits), so it works just as well for that. You can find a description of the Pronto-format here: http://www.remotecentral.com/features/irdisp1.htm

So if you want to send a raw signal on the 433MHz band via Tellstick and OpenNethome, you first have to encode the raw signal as a Pronto HEX string.
Then you can use for example the ProntoDevice Home Item. There you can enter the pronto codes and give them names that will show up as buttons in the ProntoDevice Item. Here is an example of a Pronto Item I have in my setup to control a preamp:

Image

I have actually sampled those codes from the original remote control (as pronto codes) using curcuits from here: http://wiki.nethome.nu/doku.php/homehwrec

I wonder a bit where you will get the raw signals from? Will you sample them from some existing device or do you have a description of the protocol you are going to use? If it is a protocol that is already known by OpenNethome, I would really recommend you to use the built in encoders and save yourself hours of tedious work.

perjarle
Posts: 32
Joined: Wed Aug 03, 2016 8:08 am

Re: Sending raw data

Post by perjarle » Mon Sep 26, 2016 11:03 pm

Actually, i'm not bound to any protocol yet.
It is a hobby project for building my own controller for rgb light.

It will have a cheap 433Mhz receiver and I need an easy way to send 4 bytes to it (1 for each color + brightness)
In addition to those 4 bytes it needs some addressing.

My hope is that i can use homebridge, (node-red if needed) and ONH to make it respond to Siri commands.
One way this can be done is to make a mqtt control that receive a hex string and just send it through the tellstick in a proper protocol which is easy to decode on the receiver side

I'm open for suggestions for how to solve this

I'm not experienced in working on bit level, but i have been programming Java for some years. Now i got myself an arduino and is curious to learn more.

/PJ

perjarle
Posts: 32
Joined: Wed Aug 03, 2016 8:08 am

Re: Sending raw data

Post by perjarle » Tue Sep 27, 2016 1:32 pm

Actually, if using HSL instead of RGB+brightness, it is enough to transfer 3 bytes data

stefangsbb
Site Admin
Posts: 311
Joined: Sun Nov 30, 2014 2:16 pm

Re: Sending raw data

Post by stefangsbb » Tue Sep 27, 2016 7:28 pm

Ah, then I see. Maybe the easiest would be to try to reuse an existing protocol and just reinterpret the content. If you for example use the NexaL-Protocol which sends 4 byte messages, you can encode your three bytes into the address field and your address into the button field (see the decription in https://github.com/NetHome/Coders/blob/ ... coder.java).

Then you can use the OpenNetHome protocol encoder to send the messages very easy. You also have the source code to decode the protocol in https://github.com/NetHome/Coders/blob/ ... coder.java.

To send a NexaL message you can for example telnet to a TCPCommendPort-Item and issue the command:

Code: Select all

event,NexaL_Message,Direction,Out,NexaL.Address,1234567,NexaL.Button,1,NexaL.Command,0,Repeat,10
This will send a NexaL message with the Address-field set to 1234567 and the button field set to 1.

Hope this helps!

perjarle
Posts: 32
Joined: Wed Aug 03, 2016 8:08 am

Re: Sending raw data

Post by perjarle » Wed Sep 28, 2016 7:50 am

Yes that will probably work :)

As long as I manage to write a decoder for arduino.

I found some examples online that are able to decode signals that come directly from a Nexa device.
But for some reason they dont react on Nexa commands from ONH through Tellstick

Code: Select all

/*
 * AM-HRR3 receiver test
 *
 * Homeeasy protocol receiver for the new protocol.
 *
 * This protocol isn't documented so well, so here goes (this is largely from memory).
 *
 * The data is encoded on the wire (aerial) as a Manchester code.
 *
 * A latch of 275us high, 2675us low is sent before the data.
 * There is a gap of 10ms between each message.
 *
 * 0 = holding the line high for 275us then low for 275us.
 * 1 = holding the line high for 275us then low for 1225us.
 *
 * The timings seem to vary quite noticeably between devices.  HE300 devices have a
 * low for about 1300us for a 1 whereas HE303 devices seem to have a low of about
 * 1100us.  If this script does not detect your signals try relaxing the timing
 * conditions.
 *
 * Each actual bit of data is encoded as two bits on the wire as:
 * Data 0 = Wire 01
 * Data 1 = Wire 10
 *
 * The actual message is 32 bits of data (64 wire bits):
 * bits 0-25: the group code - a 26bit number assigned to controllers.
 * bit 26: group flag
 * bit 27: on/off flag
 * bits 28-31: the device code - a 4bit number.
 *
 * The group flag just seems to be a separate set of addresses you can program devices
 * to and doesn't trigger the dim cycle when sending two ONs.
 *
 * There's extra support for setting devices to a specific dim-level that you get
 * with the HE100 ultimate remote control. I think this involves sending a Wire 11 at
 * the on/off flag position and then the message is longer with another 4 bits for dim
 * level.
 * Need to look into this.
 *
 * Barnaby Gray 12/2008
 * Peter Mead   09/2009
 */
 
int rxPin = 12;
 
 
void setup()
{       pinMode(rxPin, INPUT);
        Serial.begin(9600);
}
 
 
void loop()
{
        int i = 0;
        unsigned long t = 0;
 
        byte prevBit = 0;
        byte bit = 0;
 
        unsigned long sender = 0;
        bool group = false;
        bool on = false;
        unsigned int recipient = 0;
 
        // latch 1
        while((t < 9480 || t > 10350))
        {       t = pulseIn(rxPin, LOW, 1000000);
        }
 
        // latch 2
        while(t < 2550 || t > 2700)
        {       t = pulseIn(rxPin, LOW, 1000000);
        }
 
        // data
        while(i < 64)
        {
                t = pulseIn(rxPin, LOW, 1000000);
 
                if(t > 200 && t < 365)
                {       bit = 0;
                }
                else if(t > 1000 && t < 1360)
                {       bit = 1;
                }
                else
                {       i = 0;
                        break;
                }
 
                if(i % 2 == 1)
                {
                        if((prevBit ^ bit) == 0)
                        {       // must be either 01 or 10, cannot be 00 or 11
                                i = 0;
                                break;
                        }
 
                        if(i < 53)
                        {       // first 26 data bits
                                sender <<= 1;
                                sender |= prevBit;
                        }      
                        else if(i == 53)
                        {       // 26th data bit
                                group = prevBit;
                        }
                        else if(i == 55)
                        {       // 27th data bit
                                on = prevBit;
                        }
                        else
                        {       // last 4 data bits
                                recipient <<= 1;
                                recipient |= prevBit;
                        }
                }
 
                prevBit = bit;
                ++i;
        }
 
        // interpret message
        if(i > 0)
        {       printResult(sender, group, on, recipient);
        }
}
 
 
void printResult(unsigned long sender, bool group, bool on, unsigned int recipient)
{
        Serial.print("sender ");
        Serial.println(sender);
 
        if(group)
        {       Serial.println("group command");
        }
        else
        {       Serial.println("no group");
        }
 
        if(on)
        {       Serial.println("on");
        }
        else
        {       Serial.println("off");
        }
 
        Serial.print("recipient ");
        Serial.println(recipient);
 
        Serial.println();
}

stefangsbb
Site Admin
Posts: 311
Joined: Sun Nov 30, 2014 2:16 pm

Re: Sending raw data

Post by stefangsbb » Wed Sep 28, 2016 5:55 pm

Hmm, I think the code looks a bit weird at Latch 1. The comments (and my code) have a latch 1 one pulse of approximately 275 uS (290 uS in my code), but in the code sample they expect a first lath pulse between 9480 and 10350 uS. That does not look right.

Post Reply