-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Not Pairing #3
Comments
Hi petsch9. I want to build this. Did you manage to get it working ? |
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. |
Hi @LipcaCZ, yes, I also have the Black display like you. |
Let me know if you succed with this panel please. I already gave up. Thanks. |
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. |
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. |
Hello, |
I can confirm that the pairing mode is not working anymore.
|
Hello there |
Looks like this project was unfortunately abandoned by the author already... |
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: ***@***.***>
|
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. |
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: 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. |
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. |
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 // Transmit a wake-up message (twice, even though the real remote does it three times) while (1) {
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. |
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: ***@***.***>
|
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.. |
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 |
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
<#3 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFPBFBH753KO63L6772YDJ3W7IKTPANCNFSM5QTGF6ZQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
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. |
Dear all. I am still waiting for this to work ok. |
I have ordered a set of 433 transceivers so can test later this week. Good job, let's make this work |
Ok, So I got it all running and opened serial monitor, spits out no heater found after a while. But nothing, still no heater was detected. I am wondering a few things.
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 |
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
The text was updated successfully, but these errors were encountered: