Handle multiple zones (Q8RF)

[2225damjaich42]

I have a Q8RF receiver, with 2 thermostat. It can manage 4 circuit. I am finally succeeded to compile the code and pair with the first circuit, but i failed to pair with the second! I tried all the circuits on the receiver, but it can pair only with the first one. Of course I changed the pairing code according to the description (with HEX generator). I searched on blogs, and i found that the receiver very sensitive about the device id.

Device id last 8 bit (16+8) zone 1 --> 0111 zone 2 --> 1011 zone 3 --> 0011 zone 4 ? --> 1101 I tried to change the code for that, but i failed. If you can help me with that i would be very pleased. Again.... :)

[nistvan86]

Hi! :)

Interesting request. Truth to be told, I've never checked what the Q8RF is capable of, because I have a Q7RF which has only one receiver with a single thermostat, and a single controlled output (furnace).

I have to do some guesswork here based on the Q8RF manual, so bear with me. If I read this right, in case of the Q8RF, no matter which zone is requesting heat, the receiver turns on the furnace, and also the zone output (valve). Multiple zones can be active at the same time. If all zones stop requesting heat, it also turns off the furnace I presume. The Q8RF receiver has 5 buttons: an A/M button (which toggles automatic/manual mode on short press and begins pairing on long press, so it's the same as M/A on the Q7RF) and 4 zone buttons (on the Q7RF there's only a MANUAL button).

The main difference here (according to page 17 in the manual) is that when you activate pairing for a zone on the receiver, you have to select the same zone number on the wireless thermostat before pressing the COPY button (which sends out the pairing message for the receiver). My assumption is that each subsequent data packet sent contains the selected zone number somewhere, which in my code is currently hardwired to the first zone (probably because on Q7RF the only zone is the first zone, and I've never seen it changing during analysis of the protocol).

This is where we need to experiment, or if everything fails you could get your hands on an RTLSDR stick (I have this one) then use UHR to capture the packets sent by the original thermostat, and upload it so I can take a look. But this might be not necessary, and we might get lucky.

Every packet (28bits in length) sent out in the air has the following format in my code:

16 bit deviceID + 4 bit fixed data (1000) + 8 bit command (11111111 = Heat On, 00001111 = Heat Off, 00000000 = Pairing)

I have a hunch that the zone ID is not part of the deviceID and transmitted in a different block. My guess would be the 4bit block in the middle, which is fixed at the moment. The last two bit could be the zone identifier. It would worth a try to change that number, upload the firmware, and see if you can pair with a different zone.

This part of the packet is generated on this line. The first parameter is what you need to change (8 dec = 1000 bin), the second argument only tells what's the bitfield size is. So eg. try changing it from 8 to 9, and after flashing try pairing with Zone 2 on the receiver. If this turns out to be true, then 10, 11 are probably addressing the 3rd and 4th zones.

[2225damjaich42]

You were right! The zone packet is connecting to the 4 bit block in the middle.

I've changed the necessary line in your code to 9 from 8, but nothing happened in zone 2. I tried every letter from 8 to 15, but still nothing.

So I tried the other zones! I only can pair the zone 3, if a changed the 8 to 12!!! But it is working.

I can't figure out the logic beetween the lines: Zone 1: 8 - 1000; Zone 3: 12 - 1100; Zone 2: ?? Zone 4: ??

[nistvan86]

I think the bit order is in reverse on the receiver side, it expects MSB (most significant bit order) and I'm handling it on ESP side in LSB.

So:

• 1000 = 8 - 1st zone
• 0100 = 4 - 2nd zone
• 1100 = 12 - 3rd zone
• 0010 = 2 - 4th zone

[2225damjaich42]

And that was it!!!! :) It working now!! Thank you for your help! It was really a hard journey for me, but i've learned a lot... :) :)

Thanks again!

[nistvan86]

Great, I'm glad we figured it out so quickly. :)

Do you mind sharing how are you planning to setup the multiple zones? With the current version of the component the easiest is to assemble multiple ESPHome nodes with separate CC1101 radios, then pair each of them to a separate zone on the receiver. It might also work by having multiple CC1101 radios on a single ESP with different CS pins allocated (other SPI lines can be shared), but I've never tried this configuration, hopefully there's nothing clashing in the code which prevents this.

The reason why I'm asking is because I think it would be possible to refactor the component in such way that you could define multiple switches for each zone, but still use a single CC1101 modem, and the component will figure out internally the scheduling of the packet delivery, then you could use a single ESPHome node with a single CC1101 modem to control all zones (with multiple switches in HA). It's probably going to be a bigger refactor so not going to happen anytime soon, but it's the kind of challenge which I find interesting. :)

(As a side note: I wonder if I should reverse the deviceId when sent out, because now I'm almost sure it's also read in MSB order by the receiver. It's not making a difference because the whole identifier has to be unique anyway; but it's going to break installations on upgrade if I do so and needs re-pairing, so I don't think it's really worth it)

[2225damjaich42]

I already did it with 2 nodemcu, and 2 cc1101 for my 2 zones. :) As you described for me, every single on or off command is different in every zone, so therotically it can be work, but I know nothing about programming or codes.... :) Btw if you need a helping hand for testing, i am here... ;)

[nistvan86]

Thanks, if I have success implementing this, I will definitely ask you to test it. :) I have reopened this issue with a new name to keep track that I'm planning on doing it.

[done7k]

I already did it with 2 nodemcu, and 2 cc1101 for my 2 zones. :) As you described for me, every single on or off command is different in every zone, so therotically it can be work, but I know nothing about programming or codes.... :) Btw if you need a helping hand for testing, i am here... ;)

Hi! Just want to clarify how these two zones are organized. You have Q7FR controller and one RF receiver which attached to a water heater. But to control different zones you need Q4Z zone controller attached to each of your zone valves. How do this valve controller Q4Z and Q7RF receiver communicate to each other? or does cc1101 communicates to Q4Z device instead?

I have one zone setup but want to split it onto two (or more) separate zones. Just try to understand how I can do it and pair this all with HA.

[nistvan86]

@done7k he has the Q8RF not the Q7RF. Based on the Q4Z manual it's made for fixed wired thermostats. Q8RF is Q7RF+zone controls in one package.

I guess you can hack together a hybrid setup. Use 4 separate Q7RF receivers, wire the furnace control outputs of each to the wired thermostat inputs of Q4Z and then the Q4Z as usual to the valves and the furnace. Then you can address each Q7RF separately with this component. But using the Q8RF directly is much easier, also omits a lot of unnecessary wiring. And probably a lot cheaper :)

[done7k]

@nistvan86 . Thanks! got it.

[done7k]

@2225damjaich42 , guys, what type of valves you use? does this one work?

[2225damjaich42]

I don't know... :( I have 2 zones. 1 for the downstairs (floor heating), and 1 for upstairs. My receiver connected with 2 Grundfus pumps. If i trigger the thermostat (now in HA) it start the pumps, and the heating boiler. I think you can trigger with the receiver what you want, but you should ask a a professional about that issue.

[done7k]

Thanks guys! one more question, there is no feedback from 'receiver' to a Q(7/8)RF thermostat? I mean this small 'flame' sign on the screen (which appears while the heater is on) is shown when the thermostat sends the 'on' command and there is no guarantee it is really on? right? So, if second thermostat turns on the heater the first one will not display the real status. right? or it will show it because it receives RF signal with the same deviceID? what will be displayed?

[nistvan86]

@done7k the answer is in the FAQ, but in short: the protocol is simplex, thermostat sends, receiver receives. There's no acknowledgement for the commands. If you operate multiple thermostats with the exact same ID, the receiver doesn't know which one is controlling it. Thermostats repeating last state periodically even if there was no change for a while, so this can result in a hectic alternating state on the receiver. Each thermostat shows the "flame" icon based on it's own state, they don't listen to each other, and the icon can show up even though the receiver was not turning on the furnace (command packet gets lost and a repeat will trigger it eventually). Try unplugging the receiver and you can see the flame icon shows up even though nobody listens.

(I'm going to hide these off-topic answers in a couple days in this issue)

[done7k]

Right, missed that simplex stuff. Sorry

[ZeleiAttila]

Hi,

I have problem with pairing. In the first comment wrote @2225damjaich42 "the receiver very sensitive about the device id". Maybe can you send me a usable device id-t?

[nistvan86]

Hi @ZeleiAttila, The device ID shouldn't matter, as it's learned by the receiver. It should be something unique. I don't know if there's any sub pattern in it which is checked by the receiver, the one I'm using is something I've generated randomly as described in the documentation, and it worked for the first try.

Although, just to mention, this Github issue is for the Q8RF, and I'm using a Q7RF. Which one are you trying to use? The repo has no integration for the Q8RF zones at the moment, a requires the manual patching described above if you read back. There's an additional part in the message block which is used to address a heating zone. The Q7RF has a single virtual one, and the code is hardwired to use that.

[ZeleiAttila]

Hi @nistvan86,

I am using Q8RF. I know I should change the code when I want to use it to others zones. But if I know correctly I can use this component with first zone of Q8RF zone controller without any modification. I used same devices as you and I tried it: I pressed long the button of first zone then I called the pairing service, but nothing happened. The led next the button continued to blink.

I think I see correct messages: Issued CC1101 reset sequence. CC1101 found with partnum: 00 and version: 04 CC1101 initialized. Enqueued pairing. Handling prioritized message. Sent message: PAIR

I don't see what is the problem. When I read in this issue that the receiver very sensitive about the device id, I thought maybe it is my problem. Can you give me any advise?

[nistvan86]

I'm not sure what device ID did @2225damjaich42 use. I'm using 0x6ed5 with my Q7RF though, try using that and see if it helps.

Otherwise if you have an RTLSDR stick, you can use eg. SDR# to listen on the 868.285 MHz frequency and see if any burst shows up on the waterfall when you call the PAIR service, just to be sure the setup is working.

[ZeleiAttila]

I tried, but it did not work. I don't have an RTL SDR stick, but I have a NRF905 module. Maybe I try it. What do you think about I record the signal from the thermostat? The CC1101 is a transceiver so it can use for this. Do you have any idea how to do this?

[nistvan86]

That's unfortunate to hear :(

As far as I remember the Ti SmartRF app can do some kind of continuous sampling with the CC1101 but I haven't tried using it. I think it requires an evaluation board from Ti which can be directly connected to a PC, or you have to write a different code for the ESP8266 which can initialize the modem like that and then receive the samples and transfer them somewhere. The wiring for this project is very likely not suitable for that, because the additional PINs might be required, since the internal buffer of the CC1101 is extremely small, you have to react instantly as the data is available, otherwise you lose data. Also you find no receiving code in my repo, maybe you can use one of the original source libraries I've based this upon (end of the readme).

Even if you do so, I don't know what the format will be. The CC1101 was primary meant to be used as a modem which can decode/encode packets on it's own based on the init configuration, and the MCU controlling it will only need to deal with the high level message after that. As a sampling radio it's much more limited. An RTLSDR stick can easily capture the whole 868MHz ISM band at once into I/Q packets, and you can record, analyze whichever part you need eg. with Universal Radio Hacker. With the CC1101 trying to find out where the signal actually is and what's wrong with it would be like watching the night sky through a needle eye.

[RaTiMax]

Hi, I use CC1101 and works perfectly with Q8RF. Ordered from ali. https://www.aliexpress.com/item/32858516951.html At the moment, I only use it in zone1. Tibor

[ZeleiAttila]

Hi @RaTiMax,

I ordered from ali too, but I bought the "CC1101 868MHZ" option with short antenna. The link what you sent points the "CC1101 Green" option witth long antenna . It is correct? I can use on 868 MHZ?

@nistvan86 Maybe can you send a link, where I can buy a usable RTLSDR stick?

[nistvan86]

I have this green "NEWGEN.RTL2832 SDR" labeled stick. Strange enough I can't seem to find an item which also includes the SMA antenna, mine came with a small TV tuner antenna with a magnetic base. Be careful, you might need to buy that separately. Although, every RTL2832U chipset based stick should work for SDR, this tuner is just built with a bit better components with a metal case and drifts less as it warms up, making it more ideal for SDR.

By the way my CC1101 board is exactly as the image in the README, the 868 compatibility is stated clearly on it's silkscreen.

[RaTiMax]

Hi @ZeleiAttila, I use "CC1101 868MHZ" (3rd picture with short antenna in ali - in link)

[ZeleiAttila]

So we all use the same module, and only mine is not working. I will order a new one and try it.

[ZeleiAttila]

Hi @nistvan86!

I finally got the RTLSDR stick and new CC1101, but the paring still not working.

I recorded two ON signals, the first sent by Q8RF and the second by CC1101.(below) I don't know how to decode the signals, but at first glance the length of the two signals is different. The Q8RF signal is 400 ms, while the CC1101 is 100 ms. Do you know what could be the reason for the difference? Or it is unimportant?

[nistvan86]

It turned out my local URH installation still had the IQ recordings and protocol analysis I was working with. The correct way to interpret the signal is switching to ASK modulation. If I remember correctly selecting the signal on the scope view and hitting auto-detect once ASK is active it should figure out the correct sample/symbol. It's either 600 samples/symbol or 200 samples/symbol if I remember correctly. Then it's possible to view the signal as bits (see image.)

It locks on to the representation if there's multiple packets starting in the bit view with preamble 111000111. The original thermostat repeats the signal quiet a few times. Mine only does it like 6 times in a burst because the CC1101 runs out of memory so I couldn't repeat it that much. But it was enough for the receiver to still switch. It's only repeated to have a bigger margin of error anyway. So the length difference not necessarily means it's bad. We need to see the contents.

Anyway, if you paste the raw bits for each segment from the "Interpretation" view we can try and figure out what is the difference. Both the original Q8RF wireless thermostat, and the signal sent by the CC1101.

Note: as I remember the bit speed of the original thermostat and the one sent out by CC1101 is not totally matching, so URH will detect them with different samples/symbol. But the preamble part serves as a synchronization period for the receiver to lock on and learn the sender's speed so this should be not a problem.

---

It's possible to further analyze the bits into packets on the analysis tab if you setup it as such. But I don't remember if this setup shows the full packet. I don't think this is right, as the message is 28 bit long + and the preamble is an additional part. Anyway, I thought I archieve it here.

[ZeleiAttila]

Hi,

I tried to analyze the signals, but I have not succeeded. The CC1101 signal looks good, I see the 111000111 preamble data, but in signal of Q8RF I don't see.

I attached the signals: signals.zip