Not Pairing

[petsch9]

Hi, I like the idea, but in my case it is not working. Not pairing. Is there a way to debug or get some help.

I have a LOLIN32 and C1101 and spi connection is good also the requeired parking heater with red controller. but keeps waiting to pair until the timeout and fails

Kind regards

[franciscoasencio]

Hi petsch9. I want to build this. Did you manage to get it working ? Thanks for your comments Greetings Francisco

[LipcaCZ]

Hi @petsch9, did you solve it? I have the same problem. I push the arrow up on the heater until "HFA -" appears on the panel, but ESP will timeout and fail anyway. Pairing with standard remote works this way normally.

[dave190265]

Thanks for this fantastic library - I'm so excited to get it working.

However, I'm also not able to pair. I've tried connecting a simple Logic analyser to try and see what's going on on the SPI bus. After resetting the ESP32, I always get the following initial activity, followed by silence on the SPI Bus

When I zoom into the first burst of activity, I see this ..

Not really sure what the data means, or if this is behaving as intended ? I've tried selecting the "HFA" pairing mode on my LCD display before, during and after starting the ESP32, but never succeeds in pairing - any ideas ?

This is my hardware setup:

and I'm using a PlatformIO project like this :

[LipcaCZ]

What panel on the heater do you have? There is a condition that the panel must be compatible with that red remote with OLED display. I have this black panel and didn't succeed too and I think the problem in the compatibility. Looks like this panel can work only with that simple remote on the picture. It should probably work with this blue panel and few other kinds.

[dave190265]

Hi @LipcaCZ, yes, I also have the Black display like you. That's very disappointing - I am still keen to try and get this working if at all possible. I am currently looking at the CC1101 datasheets, learning about SPI protocol and trying to follow the code and compare with my logic analyser trace.

[LipcaCZ]

Let me know if you succed with this panel please. I already gave up. Thanks.

[dave190265]

Hi @LipcaCZ I'm still looking into this - It appears that the CC1101 module gets configured, and the software enters the receivePackets() function, but hangs on the "Wait for GD02 assertion" which never happens. I did suspect my CC1101 module, but replaced with another one, but same behaviour.

I am currently waiting for a USB SDR module so that I can monitor the existing communication between my simple RF Remote and the Control panel. (Maybe the Frequency is different and needs to updated in the configuration of the CC1101 module ?)

As a minimum, we aught to be able to replicate the ON/OFF/UP/DOWN functionality of the existing remote - but I'm not yet sure that this new control panel issues the state information ?

I'll let you know how I get on.

[Uhlfred]

I have the same problem. The display is blue, the remote control is red. The black remote control also can get paired to the blue display. Unfortunately, the pairing does not work with the ESP32. I have the CC1101 with the 8-pin header soldered on. I have already tried different ESP32, I also changed the jumper cables once. Pairing still doesn't work although HFA is written in the heater display.

[lucibuz]

Hello, I find this project OpenMQTTGateway that is compatible with CC1101 module (esp32dev-pilight-cc1101) https://docs.openmqttgateway.com/#first-ready-to-go-openmqttgateway-device I didn't have the chance to try it, maybe will help to read some data from the heater module.

[sdrabent]

I can confirm that the pairing mode is not working anymore. "Started pairing, press and hold the pairing button on the heater's LCD panel... Failed to find a heater" My process:

1. booting ESP32
2. Pressing the right arrow on diesel heater panel until "HFA" appears.
3. Timeout: "Failed to find a heater"

[MarioNava1962]

Hello there I set up an esp32 with a CC1101 module and I am not able to pair with the heater. Same tries, start ESP, pressed right arrow button on the LCD module HFA- appears but nothing happens and the error "Failed to find a heater" is displayed on the serial console. Note. The standard (red) remote still works. Any news about this? Thank you.

[LipcaCZ]

Looks like this project was unfortunately abandoned by the author already...

[MarioNava1962]

He replied me few days ago updating the download link.Anyway i Guess the project was stopped and no one, with the required skill and tools, grabbed It.So bad.  Mario NavaIl 22 mar 2023 09:17, LipcaCZ @.***> ha scritto: Looks like this project was unfortunately abandoned by the author already...

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[frspp]

I have a non-supported remote without a display, tried for fun and did not succeed in pairing. Good to know people who have red remote with display have also pairing issues.

[MKme]

Ive been working on this all weekend and I cannot see how this ever worked. The example doesnt send any packet during the find address function: uint32_t DieselHeaterRF::findAddress(uint16_t timeout) { char buf[24]; if (receivePacket(buf, timeout)) { uint32_t address = parseAddress(buf); return address; } return 0;

When pairing my blue screen with black remote + oled the heater in pairing mode waits to hear from the remote- once it does hear a burst from he remote the paring is completed. The tx is on 433.900 as expected. Sniffing this with an SDR runnting RTL_433 I can see the packet format aligns with this library and the power key command matches too, but there is where the functionality ends.

For 5 days I have been trying various tricks and to date I cannot get this to TX when using a buffer of data. The radio init DOES work and I am able to send a constant carrier if I hardcode it, but trying a TX using the data buffer yields no output despite the buffer filling correctly and running through the multiple TX cycles.

I have tonnes of video footage I'll publish on my channel when I get a bit further. I've already written the code to send the data to HA using MQTT with bidirectional control so HA can control the heater. It should work but I didnt expect the radio to be so difficult.

I have tried different register settings as the original ones in this lib seem quite odd. Mainly the PAtable seems strange but despite all efforts and using the values in the ELECHOUSE_CC1101_SRC_DRV library- I cant get to the solution yet. That library works with the radio hardware and has no problem yapping out RF all over the band. Just something in the radio init here seems to stop the radio dead and make it nonresponsive or the timing is not correct.

I havent given up yet but it sure seems to me like this code never worked but since the values seem legit- perhaps the author just forgot to commit a new version. Hmmm should check the commit history too as it maybe wen backwards.

I also designed a PCB already to make this a simple DIY kit for Home Assistant- just didnt expect the radio to kick my butt this much. Update soon. Video soon.

edit I should also mention in case not clear- the SPI does init properly and can see the chip ID/rev on the radio as 15 on mine. It seems to respond normally in all respects other than buffer TX. Congig as a constant carrier send by putting tx in setup works no problem. Eric

[LipcaCZ]

Or maybe there was functional version earlier and then he commited wrong one and broke it? :) Maybe try to look on older commits. I know only very little about programming Arduino, so can't say what's wrong, but maybe try to ask some AI? It already helped me with some scripts in Blender. phind.com is my favorite for those things.

[MKme]

Yep thats why I wrote this: perhaps the author just forgot to commit a new version. Hmmm should check the commit history too as it maybe wen backwards.

Looking back it seems the author always had the address 0x56d24eae (if Im reading it right) and some time back swapped the initialization from:

heater.begin(heaterAddr);

// Test reading the CC1101 version number uint8_t tmp = heater.writeReg(0xF1, 0xFF); Serial.printf("CC1101 version is %d\n", tmp);

// Transmit a wake-up message (twice, even though the real remote does it three times) for (int i = 0; i < 2; i++) { heater.sendCommand(HEATER_CMD_WAKEUP, heaterAddr, 15); }

while (1) {

heater.sendCommand(HEATER_CMD_WAKEUP, heaterAddr, 10);

if (heater.getState(&sState, &sPower, &sVoltage, &sAmbientTemp, &sCaseTemp, &sSetpoint, &sPumpFreq, &sAutoMode, &sRssi, 1000)) {
  Serial.printf("State: %d, Power: %d, Voltage: %f, Ambient: %d, Case: %d, Setpoint: %d, PumpFreq: %f, Auto: %d, RSSI: %d\n", sState, sPower, sVoltage, sAmbientTemp, sCaseTemp, sSetpoint, sPumpFreq, sAutoMode, sRssi); 
} else {
  Serial.println("Failed to get the state");
}

delay(HEATER_POLL_INTERVAL);

to

uint32_t address = heater.findAddress(60000UL);

This may be what broke the function as it no longer sends a wakeup with a predefined adress (which should work id the RX is in bind) It is also interesting all this was initially done outside the loop- this is the one time I get a carrier is when I test hard setpoints in a setup call.

I'll play more tonight.

[MarioNava1962]

Wow! Great job! Also because in the sample code there are no instructions about how to send i suspect this Is a project started but abbandoned. So bad. Will look forward your progress. Unfortunately i don't ha such skill and tools like you. Thank you!Mario NavaIl 27 mar 2023 18:10, Eric @.***> ha scritto: Ive been working on this all weekend and I cannot see how this ever worked. The example doesnt send any packet during the find address function: uint32_t DieselHeaterRF::findAddress(uint16_t timeout) { char buf[24]; if (receivePacket(buf, timeout)) { uint32_t address = parseAddress(buf); return address; } return 0; When pairing my blue screen with black remote + oled the heater in pairing mode waits to hear from the remote- once it does hear a burst from he remote the paring is completed. The tx is on 433.900 as expected. Sniffing this with an SDR runnting RTL_433 I can see the packet format aligns with this library and the power key command matches too, but there is where the functionality ends. For 5 days I have been trying various tricks and to date I cannot get this to TX when using a buffer of data. The radio init DOES work and I am able to send a constant carrier if I hardcode it, but trying a TX using the data buffer yields no output despite the buffer filling correctly and running through the multiple TX cycles. I have tonnes of video footage I'll publish on my channel when I get a bit further. I've already written the code to send the data to HA using MQTT with bidirectional control so HA can control the heater. It should work but I didnt expect the radio to be so difficult. I have tried different register settings as the original ones in this lib seem quite odd. Mainly the PAtable seems strange but despite all efforts and using the values in the ELECHOUSE_CC1101_SRC_DRV library- I cant get to the solution yet. That library works with the radio hardware and has no problem yapping out RF all over the band. Just something in the radio init here seems to stop the radio dead and make it nonresponsive or the timing is not correct. I havent given up yet but it sure seems to me like this code never worked but since the values seem legit- perhaps the author just forgot to commit a new version. Hmmm should check the commit history too as it maybe wen backwards. I also designed a PCB already to make this a simple DIY kit for Home Assistant- just didnt expect the radio to kick my butt this much. Update soon. Video soon.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[MKme]

Small update since this is as good of place as any to do it. I went back and started over cobbling together some of the older code from here and I was able to finally get it to transmit seemingly okay bursts of the wakeup command YAY. I didnt decode them with the sdr to check the packets but I can do that later easily as I was able to do with the remote.

When I re-implemented a newish version of the find address function- this is what totally breaks the radio function as soon as it runs- I didnt bother to debug it and instead just made a basic version which should work. With that done and replaying the live captures with the HackRF I saw nothing in the receive buffer. Traced this back to the register from the code here had GDO2 set seemingly wrong. Swichted it to assert high on packet receive and de-assert when FIFO is empty. This finally got to a point where it looks legit on the scope and waterfall- it is sending packets and seemingly ready to receive but nothing coming back from heater data in my recordings. In the few times I got the code to recognize a GDO assertion and send me a serial message- the buffer was actually empty with zero bytes in the FIFO. I'll try on the live hardware tomorrow but its very likely other registers are also set incorrectly for things of critical importance. I could be completely missing the forest through the trees too and none of what I have done was necessary :)

Here is a happy picture at least- packets on the waterfall, serial data from the esp32 and GDO2 assertion on the scope. Im tired..

[MKme]

I guess I will just keep updating here. I really cant figure out how this ever worked- so much matches up but just doesnt work. Tonight Im still able to TX but no matter what I try I cannot get it to receive and decode the packets in the air. I reimplemented the original code to decode the address from the packet and nothing.

I was able to verify 100% that the packets sent from my remote match the code here. The address should be a 32 bit value and is extracted from the 3rd to the 6th bytes in the received buffer.

uint32_t CC1101_Heater::parseAddress(char *buf) { uint32_t address = 0; address |= (buf[2] << 24); address |= (buf[3] << 16); address |= (buf[4] << 8); address |= buf[5]; return address; } For mine:

Using this function, the address would be parsed as follows: buf[2] = 0x2B buf[3] = 0x03 buf[4] = 0x84 buf[5] = 0xB9 Which results in the 32-bit address: 0x2B0384B9

The received data appears to be 24 bytes long, which is the expected length according to the receivePacket() function: if (rxLen == 24) break;

Additionally, the power key press command (0x2B) is present in the received data. This is the key I was pressing when I captures the data. Yay.

To check if the CRC in the packet matches the CRC function, we need to compare the CRC value calculated from the first 19 bytes of the packet to the CRC value present in the packet itself. 55 55 55 55 55 55 55 55 09 1a 2b 03 84 b9 b8 29 00 00 00 00

The CRC value in the packet is stored in bytes 19 and 20: CRC_high = buf[19] = 0x00 CRC_low = buf[20] = 0x00 So, the CRC value in the packet is 0x0000.

calculate the CRC from the first 19 bytes using the crc16_2() function: uint16_t crc = crc16_2(bytes, 19);

If the calculated CRC value matches the CRC value in the packet (0x0000), then the CRC in the packet is correct, and the packet is considered valid. If not, its junk and discarded.

Im still not sure it is a match yet since Im too dumb for this function and GPT4 is losing its marbles tonight. If I can prove it matches- the code really checks out and It's even more strange that there is so much trouble.

I'll hardcode the address tomorrow and see if the heater responds to the packets sent which will prove out the radio registers etc. If not- this may explain the lack of receive if there is still a register or more wrong for the needed setup.

[MKme]

Best guess at this point is this radio module is not even capable of decoding this since it is m=FSK_PCM: This specifies the modulation type as Frequency Shift Keying with Pulse Code Modulation. The signal is first demodulated from FSK to a pulse stream, then the pulse stream is decoded using PCM. Only way I see this happening is using raw.

You can decode this using rtl_433 with the command: rtl_433 -d driver=hackrf -X 'n=name,m=FSK_PCM,s=416,l=416,r=425984'

skip the hackrf driver if using a standard sdr like an r820t.

I think I give up

[frspp]

Could you share the (full) radio signal each remote button sends? I’m hoping to make one way (send only) remote someday.

On Mon 3. Apr 2023 at 3.28, Eric @.***> wrote:

Best guess at this point is this radio module is not even capable of decoding this since it is m=FSK_PCM: This specifies the modulation type as Frequency Shift Keying with Pulse Code Modulation. The signal is first demodulated from FSK to a pulse stream, then the pulse stream is decoded using PCM. Only way I see this happening is using raw.

You can decode this using rtl_433 with the command: rtl_433 -d driver=hackrf -X 'n=name,m=FSK_PCM,s=416,l=416,r=425984'

skip the hackrf driver if using a standard sdr like an r820t.

I think I give up

— Reply to this email directly, view it on GitHub https://github.com/jakkik/DieselHeaterRF/issues/3#issuecomment-1493486091, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFPBFBH753KO63L6772YDJ3W7IKTPANCNFSM5QTGF6ZQ . You are receiving this because you commented.Message ID: @.***>

[deanfourie1]

@MKme

Be the real savior and start a new repository.

You seem like you are the man for the job. We will all love you haha.

[franciscoasencio]

Dear all. I am still waiting for this to work ok. I have Blue unit + black oled remote. You will all lough about me but I just finished trying to capture the codes send by the remote using cheap 433 RF receiver and rc-switch library for arduino. Of course it did not work. Works ok with my garage opener unit. And following the authors instructions I opened the remote to look inside and identify the RF chip used. To no avail and found a nice microcontroller inside labeled HK32F030MF4P6. ( of course , it has to control de the oled screen ) . No RF chip in sigth. Other than the microcontroler there is only one chip there labeled 300A S961 045. There is also a crystal JZ0K15 26.000M. So, back to bussiness and received mail with last comment by @deanfourie1 .... Y second his suggestion and offer my help, since I too want to integrate with Home Assistant. I loaded the repository in Visual studio and begin to study the functions. I too noted that the function to get the adress for pairing does not send anything to the controller , and then I remembered the way my unit does the paring.......... After entering paring mode in the controller i.e. "Press UP button AND CONFIRM button for 3 seconds until HFA displayed ..." And her comes the important part "When HFA displayed, press POWER button to send code to the remote and finish the pairing." So, it would be interesting to check this procedure as it confirms that the Get adress function only wait for the code to be send by the central unit.( When pressing POWER button while in HFA !!! ) I do not have the hardware yet, but recommend to try out by thos who have it. I will order of course Maybe we all get lucky. Greetings Francisco

[deanfourie1]

I have ordered a set of 433 transceivers so can test later this week.

Good job, let's make this work

[franciscoasencio]

@deanfourie1 Will this work ? Thank you. Greetings https://es.aliexpress.com/item/1005004333776584.html?spm=a2g0o.detail.1000014.3.48eb3e47UTj4kg&gps-id=pcDetailBottomMoreOtherSeller&scm=1007.40050.281175.0&scm_id=1007.40050.281175.0&scm-url=1007.40050.281175.0&pvid=b9a509f1-2f2e-4b16-9284-96e80cb4fe13&_t=gps-id:pcDetailBottomMoreOtherSeller,scm-url:1007.40050.281175.0,pvid:b9a509f1-2f2e-4b16-9284-96e80cb4fe13,tpp_buckets:668%232846%238115%232000&pdp_npi=3%40dis%21CLP%212305.0%211847.0%21%21%21%21%21%402101ec1a16840204830914020e1b89%2112000028795290287%21rec%21CL%21190718436

[deanfourie1]

@deanfourie1 Will this work ? Thank you. Greetings https://es.aliexpress.com/item/1005004333776584.html?spm=a2g0o.detail.1000014.3.48eb3e47UTj4kg&gps-id=pcDetailBottomMoreOtherSeller&scm=1007.40050.281175.0&scm_id=1007.40050.281175.0&scm-url=1007.40050.281175.0&pvid=b9a509f1-2f2e-4b16-9284-96e80cb4fe13&_t=gps-id:pcDetailBottomMoreOtherSeller,scm-url:1007.40050.281175.0,pvid:b9a509f1-2f2e-4b16-9284-96e80cb4fe13,tpp_buckets:668%232846%238115%232000&pdp_npi=3%40dis%21CLP%212305.0%211847.0%21%21%21%21%21%402101ec1a16840204830914020e1b89%2112000028795290287%21rec%21CL%21190718436

As far as I know anything that supports the cc1101 chip will work

[deanfourie1]

Testing

[deanfourie1]

Ok,

So I got it all running and opened serial monitor, spits out no heater found after a while. Rebooted the ESP32 and immediately went to the heater and help the "DOWN" button until HFA was displayed. As far as I know, this is all you need to do. It displayed "HFA" on the screen.

But nothing, still no heater was detected.

I am wondering a few things.

1. Has this ever actually worked for anyone? - based on the issues, I cant see anyone with an issue where this is actually functioning.
2. Is it possible that only 1 remote can be paired at a time. Maybe we need to unpair or forget the original remote in order to pair a new one?

Hopefully I have all my wiring correct. As per the diagram shown i've assumed SI is MOSI and SO is MISO.

I am interfacing with a board like this

https://amptech.co.nz/NRF24L01-Socket-Adapter-Board-5V-to-3.3V

and this transceiver.

https://amptech.co.nz/CC1101-Wireless-Transceiver-Module-SMA-Antenna-Arduino-433MHZ?search=433