OK, the 3 messages seem's to be always the same for an action (On -> Off and Off -> On) ?
Only first14 bytes are probably needed just as for my Heaters.
Just hope that sending the full message is not necessary, since my code actually doesn't handle messages bigger than 60 bytes due to CC1101 buffer limitation, But it should not since we don't need 74 bytes to say a boiler to turn On/Off
For my Heaters, Deltia 8.33 send 2 messages :
- 1rst message is to handle Eco/Comfort Mode
- 2nd message is to handle Power On/Off and HD Mode
Even if it's not really necessary, you will have to understand what the 3 messages are used for.
I've started capturing radio traffic for the past 19 hours.
I have captured 22 different frames/messages.
The first 14 hex characters of these are all different.
For better visibility, I have assigned/identified each message with a character (A, B, C, etc.).
The distribution of all messages since I started capturing goes like this:
89 : E
59 : D
59 : C
48 : F
42 : T
42 : R
36 : B
23 : U
23 : Q
22 : I
17 : H
6 : M
5 : S
5 : G
1 : W
1 : V
1 : P
1 : O
1 : N
1 : L
1 : K
1 : J
The ones that show up less than 10 times are junk (series of 0's) and/or messages that are not used often or even come from other devices.
Using a perl script to provide and understandable output from rtl_433 (capital letter corresponds to a known frame/message + timestamp) here is what I get when turning on:
C : 2016-01-26 12:50:26
D : 2016-01-26 12:50:26
E : 2016-01-26 12:50:29
G : 2016-01-26 12:50:30
E : 2016-01-26 12:50:32
F : 2016-01-26 12:50:32
C : 2016-01-26 12:50:38
D : 2016-01-26 12:50:38
E : 2016-01-26 12:50:46
F : 2016-01-26 12:50:46
E : 2016-01-26 12:50:47
G : 2016-01-26 12:50:47
Basically, CDEGEF messages are sent, by pairs, in a 3 to 5 seconds time window. Then, these are repeated, later, more slowly, and not always exactly in the same order.
Turning on again, I get same in different orders (pairs remain together, though): EG CD EF then CD EG EF
The same when turning off:
E : 2016-01-26 12:53:43
B : 2016-01-26 12:53:43
C : 2016-01-26 12:53:45
D : 2016-01-26 12:53:45
E : 2016-01-26 12:53:46
F : 2016-01-26 12:53:46
E : 2016-01-26 12:53:57
F : 2016-01-26 12:53:57
E : 2016-01-26 12:54:02
B : 2016-01-26 12:54:02
C : 2016-01-26 12:54:07
D : 2016-01-26 12:54:07
I would have expected the thermostat to send only 1 message (and maybe to repeat it multiple times to make sure the other receives it) but I am surprised than many different messages (6) are sent for each scenario. Also surprising that do not get replayed consistently.
Does the protocol of your device work the same way ?
Deltia 8.33 only send 2 messages per action and it's repeated once about 30 (or 15) seconds later.
As already said 1rst message is "Comfort/Eco" mode, 2nd message is "Power On/Off/HG" mode.
Message order has probably no real matter, but it's usualy always the same.
It will be a good idea to read Deltia 8.03 documentation again to have a bit more informations on all functionnalities.
To be sure, in your scripts you must only capture data starting with 55 7f (preamble + Synch byte).
If you can, try to put Action done asside all messages (Power On -> Off or Power Off -> On)
Also try to catch "Signal/Level" for each messages to be sure that Deltia 8.03 is not talking in "bi-direction" mode.
I think that driving your boiler with an RFBee is possible, but I'm a bit less confident than yesterday.
If experimenting, we may find that only 1 message per action is necessary for Boiler and others are destinated to some extra devices or some extra functionnalities, but at this state we can't be sure.
All messages have that 55 7 preamble. I'm trying to get an older RFM12b transceiver to work on an arduino to send the same frames (but I haven't yet managed to get it working, might be dead...) before spending money on a RFbee. Replaying the various messages shall be good enough.
As for the bi-directional, I could check that indeed.
RFM12B seem's to be a FSK Modulation Tranceiver but Deltia seem's to use OOK/ASK modulation.
I'm not sure RFM12B can technically talk to any Deltia receiver.
And don't forget that captured data has been Manchester decoded by RTL_433, you need to Manchester encode messages when sending.
Reading Deltia 8.03 documentation, here is what I think :
- Emitter don't know what device is associated. (It's the same with Deltia 8.33)
- Deltia 8.03 can command a boiler, a circulator, heaters and maybe few other devices.
- Deltia send messages to all possible devices associated as X2D may have a specific message for each devices (you probably have 1 or 2 messages for boiler, 2 messages for Heaters and messages for other devices)
Thanks for digging this up. I've read the page and the modification of the board is no trivial enough for me so I'll have to go ahead and purchase an RFBee.
Just to make sure I'm buying the right components and needed adapters, what exactly do I need to purchase to have it running on a raspberry pi ? (any pointer to amazon/ebay links much appreciated )
thanks
RFbee is said to be V1.1, but it should be a V1.2 with an ATmel328 in place of ATmel168 (more memory and faster Serial)
Can be delivered in less than a week
Directly from china, you don't really know what you will get... but it's cheaper
My suggest, buy in france, you know what you will get and you should be able to receive hardware before end of week or at worst before end of next week (depending on your shipping choice)
I received the board and USB adapter. Thanks a lot for the links.
So it kind of works (the same signal will stop the boiler but I have to try 2 different signals to stop it. I'll further dig and figure something out.
The main issue I am having right now is the range. The RFBee is currently 4 meters away from the receiver (no walls in between) and, unless I point the antenna (which I have unrolled a bit) straight to the receiver, it does not seem to receive anything. While the DVB-T (also 4 meters away) gets it everytime.
Is there a way to improve the range ? I tried looking for antennas for the rfbee but it does not look like a lot of people have already tried putting a "bigger " one.
You should not have any problem with Range.
I didn't touched Antenna of my RFbee and signal is received by all my heaters at more than 4 meters with walls and stairs.
Maybe you should check that RFBee is on exactly same frequency than your Deltia emitter.
For this you will have to use a tool to trace a "waterfall".
You can use SDRsharp on Windows or GQRX on Linux.
Try to visualize both signals on the same waterfall. Idealy signals should be on the same vertical line.
If there is a big difference between frequencies, you will have to tweak RFBee (CC1101) Frequency
This can be done in cc1101.h file with the following parameters :
#define CC1101_DEFVAL_FREQ2_868 0x21 // Frequency Control Word, High Byte
#define CC1101_DEFVAL_FREQ1_868 0x65 // Frequency Control Word, Middle Byte
#define CC1101_DEFVAL_FREQ0_868 0xC4 // Frequency Control Word, Low Byte
You can use SmartRF Studio7 (tool for CC110x chips family from Texas Instrument) to help you.
Maybe you can play with PA_TABLE too, but I don't remember if this is used with CC1101 parameters I've set.
This can be done in this file CC1101-X2D-Heaters.ino :
Thanks for the very quick reply. I've compared frequencies of both my thermostat and the rfbee. These were pretty much the same.
For some reasons, it now works, with the sender/receiver being 6 meters apart and a thin wall in-between (which will be the final locations) so this is good this way.
The python script to send commands does not work for me (I am using echo Command >/dev/ttyUSB0 instead but then not getting the ouput):
python pyX2DCmd.py On
Traceback (most recent call last):
File "pyX2DCmd.py", line 17, in <module>
ser.open()
File "/usr/lib/python2.7/dist-packages/serial/serialposix.py", line 271, in open
raise SerialException("Port is already open.")
serial.serialutil.SerialException: Port is already open.
As for the code, should you want to extend your script, here is what I have added. The long list of signal is only meant to do exactly as the thermostat does, though sending only one of those signals will work most of the time (so for the few times where it does not work then the other signal might be useful).
@jmbjmbjmb,
Yes, I think adding a BoilerOn/BoilerOff command but if you could check which messages are necessary, this would help to keep the minimal design I try to keep.
I tried to "save on" messages to send (i.e., skipping the ones with 00's for example) but then it beame unreliable (i.e., boiler would not always turn on/off).
The messages I am sending (6 pairs of messages in a row when turning on/off) are exactly what the thermostat is sending. Hald of them are 00's although they are put to different variable names (so you can save some here).
As already said, you probably only need 1 or 2 messages to control the boiler, other messages are probably destinated to other devices. (heaters, alarm, ...)
No, the 6 messages are always sent when turning on or off. I have monitored the thermostat for around 20 hours and was able to confirm this with a large sample.
Although, you may indeed turn off/on with only 1 of the 6 messages, this proves to be unreliable (dont know why, sometimes when playing the 1 message that turns on/off the boiler won't accept it), while when playing the sequence of 6 messages it always works.
as an attempt to contribute, here's what I could afford to do today :
log the reception on the Mydomokit USB device (basically a manchester modem with a pic / USB serial inside). I wasn't able to find any possible comparison with my logs or the structure what is sent by my deltia unit. I'm assuming the device rephrases the protocol to chat with the mydomokit program. Still, some structure is visible there, probably like sixK has said, 2 messages in a row, one for changing eco/comfort and the other for turning it on. You can easily guess in the message structure that the last digit of the message is an offset concerning the zone or the heater #
I've tried replying the exact same things to the serial port, no dice, nothing happens.
zone 1 sun => moon
00 0C 9E 06 05 00 05 90 01 00 FE B5
00 0C 9E 06 05 00 05 90 02 07 FE AD
00 0C 9E 06 05 00 05 90 02 07 FE AD
00 0C 9E 06 05 00 05 90 01 00 FE B5
zone 1 moon => sun
00 0C 9E 06 05 00 05 90 01 03 FE B2
00 0C 9E 06 05 00 05 90 02 07 FE AD
00 0C 9E 06 05 00 05 90 02 07 FE AD
00 0C 9E 06 05 00 05 90 01 03 FE B2
zone 2 sun => moon
00 0C 9E 06 05 01 05 90 01 00 FE B4
00 0C 9E 06 05 01 05 90 02 07 FE AC
00 0C 9E 06 05 01 05 90 01 00 FE B4
00 0C 9E 06 05 01 05 90 02 07 FE AC
zone 2 moon => sun
00 0C 9E 06 05 01 05 90 01 03 FE B1
00 0C 9E 06 05 01 05 90 02 07 FE AC
00 0C 9E 06 05 01 05 90 01 03 FE B1
00 0C 9E 06 05 01 05 90 02 07 FE AC
zone 3 sun => moon
00 0C 9E 06 05 02 05 90 01 00 FE B3
00 0C 9E 06 05 02 05 90 02 07 FE AB
00 0C 9E 06 05 02 05 90 02 07 FE AB
00 0C 9E 06 05 02 05 90 01 00 FE B3
zone 3 moon => sun
00 0C 9E 06 05 02 05 90 01 03 FE B0
00 0C 9E 06 05 02 05 90 02 07 FE AB
00 0C 9E 06 05 02 05 90 01 03 FE B0
00 0C 9E 06 05 02 05 90 02 07 FE AB
non freezing
00 0C 9E 06 05 00 05 90 01 03 FE B2
00 0C 9E 06 05 00 05 90 02 05 FE AF
00 0C 9E 06 05 01 05 90 01 00 FE B4
00 0C 9E 06 05 01 05 90 02 05 FE AE
00 0C 9E 06 05 02 05 90 01 03 FE B0
00 0C 9E 06 05 02 05 90 02 05 FE AD
00 0C 9E 06 05 01 05 90 01 00 FE B4
00 0C 9E 06 05 02 05 90 01 03 FE B0
00 0C 9E 06 05 00 05 90 01 03 FE B2
00 0C 9E 06 05 00 05 90 02 05 FE AF
00 0C 9E 06 05 01 05 90 02 05 FE AE
I've also re logged properly the deltia unit on which I had added a tap port.
My settings with the logic analyzer are :
- 2400 bit/sec (aka 4800 Hz)
- manchester
- negative edge = binary zero
- least significant bit sent first
Here are the log for 2 zones. I'm getting a structure close to what SixK described. Exported with HEX radix only. I clearly get the right delimiters (55). I still don't know why there are other garbage after the 14 first useful ones. I suspect that the deltia unit refreshes ALL zones each time there's a change, just in case. The message is doubled (I didn't check if it's exactly the same) 1 second after the first one in case there was a collision I suppose, as it's not bidirectional comm.
double post... I didn't find the right settings for the manchester decoding (brain fart, flu is there).
- 2400 bit/sec seems ok
- negative edge is a binary one
- MSB sent first
this gives me values that are totally similar to what SixK has
HIS :
byte SunArea1[14] = {0x55,0x7f,0x5d,0xa4,0xca,0xaa,0xcd,0x52,0x2a,0xea,0x81,0xc8,0x7f,0xc0};
Now I've tried to send those to my unit and it doesn't work. No blinking nothing. I've used your code from the git, I'm wondering if it's updated or if I should look for least significant bit things / errors
so I'll have to go ahead and purchase an RFBee.