433 Protocol and Timing

The various protocols and message formats for sensors are listed on this page. As I developed a received programs based on my own sensors, my naming in LamPI might be different from that is accepted as the correct naming, but in general that does not matter.

Version 3.6 alpha
Date: August 2015. The page will be under construction for a while

We will start with a set of common devices (switches and dimmers) followed by a description of sensors protocols (weather stations). The following devices are fond on this page:

• Kaku (Klik aan klik uit)
• Impuls, Action
• Livolo switches
• Kopou switches
  
  
• UPC/Esic weather stations
• Auriol Temperature sensor

The reason why this page is in the development section rather than the hardware section is that the trasnmitter codes are all software and not hardware related. The hardware layer for all transmitter functions is equal.

Kaku (Klik aan klik uit)

We mean the new self-learning type of klik-aan-klik-uit equipment that has no wheels for address (housecode) and channel settings. As a result, the codes are longer particularly the adresses to avoid overlap and more or less guarantee that every remote sold has a unique value (so the neighbours have their own house codes).

• klikaanklikuit remotes

There are more devices with this codec, however as we do not have them in house, none can be documented to work yet.

timing

       _
Sync: | |_________________|  (T,10.5T)
      _   _
'0': | |_| |_____            (T,T,T,5T)
      _       _
'1': | |_____| |_            (T,5T,T,T)
      _   _
dim: | |_| |_                (T,T,T,T)
       _
Stop: | |_________ .. _____| (T,40T)

T = Pulase period of ~260µs.

bit code

This bit-code is simple for Kaku: Most bits are for address selection which must be uniue as the receivers are self-learning (and every handset therefore has to be shipped with a unique address code to recognize THAT handset/remote)

The last 4 bits are OPTIONAL and will only present when sending a dimmer message. A dimmer message will have a special bit 27. If that is 2(!) we have a dimmer message and bits 32 to 35 will be there to code the dimmer value.

legend

SYNC and STOP bits are ot included in the legend as they have no content but are needed to make the receiver aware that a message is coming (and hopefully other transmitters will shut-up in between). Well, the Epic ones for example do not shut up ...

As the Kaku protocol is not fast and takes some time to transmit ....  be aware that other will from time to time break into the protocol.

Impuls

Action receivers are part of a family of remotes that all use more or less the same message format. Other members are:

• Old Klikaanklikuit remotes (with a wheel)
• Impuls sets, sold  by Action stores
• Blokker

Under the hood these sets all use the same technology and chips.

timing

      _     _
'0': | |___| |___   (T,3T,T,3T)
      ___   ___
'1': |   |_|   |_   (3T,T,3T,T)
        _     ___
float: | |___|   |_ (T,3T,3T,T) used in addresses. Coded as "2"
       _
Sync: | |___________ .. ___________| (T, 31T)

T = 300uSec


bit code

Every message consists of 12 bits. The first 5 bits are address, the next 5 bits contin the device coding and the last 2 bits contain the value (on or off). Actually, bit values is not quite the correct way of saying: Every "bit" can in fact have 3 values.

legend

Livolo

Livolo makes wonderful switches and dimmers and some can be controlled by a remote. HOWEVER, their protocol is simple and pollutes the air and makes the receiver interrupt function works hard. So, this would be a protocol to delete from your system if not used.

timing

Livolo timing:
   ___
  |   |___| T + T is a 0 bit

   _______
  |       | 2T is a 1 bit

   _____________
  |             | 3.5T is a Start bit



Every message starts with a start pulse of 520 uSec

There are 16 bits address pulses: 150+150 for a 0-bit and 300 for 1-bit
And there are 8 bits for Device id: 150+150 or 300 uSecs

Each bit is approx 300 USec long, either 150+150 or 300


1 start pulse
16 address pulses
7 unit pulses

bit code

legend

The command toggles the state of the normal units. So if the unit s now switched on, another command with the same address+unti will switch it off again. The problem wih the Livolo system is therefore that unless you look at the switch or lamp and see what the current state is there is no way to switch a device on or off from a distance. It will just toggle the current value if received well by the wall switch.

So there is no on or off code. By chosing a special unit code, all associated units are switched off.

Kopou

Same as Livolo. Kopou makes a set of devices that look the same, and their protocol is almost the same as well. So lots of (re)transmissions of codes and heavy load on the receiver to recognize these messages.

timing


          _______
Start: |_|       | (T,5T)
        ___
'0': |_|   |       (T,2T)
          _
'1': |___| |       (2T,T)

Every message starts with 2 periods start pulse: 140 + 600 uSec
There are 16 bits address pulses: 140+260 for a 0-bit and 260+140 for 1-bit
And there are 8 bits for Unit: 140+260 or 260+140 uSecs

bit code

legend

UPM/Esic (WT440)

Supported devices:

• WT-440h
• WT-440
• WT-450
•  etc etc

I do have three WT-440 devices that report temperature and humidity around the house. Well, two of them (WT-440h) also report the humidity, one (WT-440) does not. The UPM sensor allows setting a few things by the user:

• House-code, to be set 1-15
• Channel, to be set 1-4
• Reporting degrees in Fahrenheit or Celcius (local display, not important for the receiver side)

timing

        _
'1': |_| | (T,T)

'0': |___| (2T)

Timing T for the pulses is around 1000 uSec (1mSec) for T

bit code

For the WT-440 temperature/humidity sensor, the house code is between 1 and 15, which is over the air reported as 0-14, and the channel is reported as a value of 0 to 3. The UPM message format is a 36-bit code as follows:

legend

The temperature is calculated as: ( received + 50 ) * 128. For integers it is better to rewrite: (received * 128) + 6400 and this way all values are positive (not signed). When sending over the line to the daemon, we will multiply by 10 to remove fractional parts! (as the resoution is 0.1 degree between 0 and 40 degrees anyway).

According to the nethome website, the UPM protocol also supports wind, windspeed and rain sensors. However, their protocol description differs from what I saw myself as the corect protocol. You find my protocol description above (which is same as Jaakko published).

• If the house code is 10, and channel code is 2, wind speed and wind direction are reported (instead of temperature and humidity) in the same message format.
• If the house code is 10 and channel code is 3, then rain fall is reported on the position of humidity bits.

I found the following pages with protocol description:

• Jaakko Ala-Paavola's page. Jaakoo did a write-up based on work of a Norwegians Johan Adler and Øyvind Kaurstadearlier in 2005.
• UPM Nethome page ; found this one long after analysing myself and making my own programs. Unsure whether this is correct

I did build support for

• wt440h receiver in ~/receivers/sniffer/sniffer.c (direct connect to Raspberry)
• wt440 receiver on http://github.com/platenspeler in Arduino Gateway library
• wt440 transmitter(!!) on http://github.com/platenspeler in Arduino Gateway library so it is possible for Arduino Gateway to emulate the protocol.

Updates LamPI version 3.5

The 3 'Byy' its described above are normally a constant with value 6 (0x110). However, although the first bit might(!) signal the battery condition the other 2 are unknown and considered a constant.

Out of the box the WT440 protocol is not suited for sending any other info than temperature and humidity, be it that the Nethome page mentions some reserved addresses (address 10) be used for wind and rain reporting.

If we would like to use the same trick for reporting airpressure, we can of course reserve another address. But it would also be possible to (mis-)use the constant yy bits in the protocol and use them for setting the information to airpressure. If we then would like to report the values of a BMP085 or BMP180 device (which are cheap) then we need room in the message for both the temperature and the airpressure. The 'HHHHHHH' 7 humidity bits to not offer much room to play, as their value is between 0 and 127 and therefore too small to encode airpressure. However, as we would be happy with airpressure readings in one(1) HpA accuracy to if we would use an offset of 930, we would be able to report airpressure readings between 930 and 1056 in these 7 bits. For the Netherlands that is sufficient as never we recorded values above 1050 Hpa and never lower than 950, but if you live in areas with storms etc. you might want to use a different scale.

Of course this would ONLY work in my house if Arduino Sensors are used and if I modify the wt440Receiver function in the Arduino library.

Auriol

The Auriol sensor is from a cheap weather station sold by LIDL in the Netherlands. It only reports temperature, but as it's ange compared to the Epic WT-440 is much better, I use it to measure outside temperature around my home.

timing

The Auriol sensor uses a pulse length of around 500 uSec. Every message is preceded by a SYNC bit. It's bit coding and timing is as follows:

       _
Sync: | |_________________| (T, 18T)
        _
  '1': | |________| (T,8T)
        _
  '0': | |____| (T, 4T)

bit code

legend

It is not possible to set anytthing on the Auriol weather sensor itself. But its protocol is simple and reliable.

Auriol is NOT supported in direct connected receivers, however it IS supported by the Arduino Gateway and the Arduino Repeater (but for the latter its protocol is converted to wt440 protocol).

LamPI own protocol

We might develop our own protocol that should enable sending and receiving all kind of messages between an Arduino and the Raspberry over 433 MHz transmission. Thinking about doing this, the protocol must be simple to understand and different from the other ones that we support by the Arduino Gateway. It is challenging to develop someting big, allowing several bytes to be sent to the remote side. However, for sensor messaging and clock setting etc. a long word is often enough.

timing

       _
Sync: | |_________________|  (T, 20T)
      _     _
'0': | |___| |___            (T,3T,T,3T)
      ___   ___
'1': |   |_|   |_            (3T,T,3T,T)
      _   ___
dim: | |_|   |___            (T,T,3T,3T)
       _
Stop: | |_______ .. _____|   (T,40T)

T = 100uSec

bit code

legend