G-Two / smoke-x-receiver

An ESP32+LoRa application to bridge a ThermoWorks Smoke X remote thermometer to Home Assistant via MQTT
MIT License
14 stars 5 forks source link

ESP32 Flashed but now cannot connect to the AP #3

Closed MikonosII closed 2 years ago

MikonosII commented 2 years ago

I see Smoke X Receiver show up in the SSID search briefly occasionally but not every time I reset the esp32. When I do and put in the password, it says its unable to connect and then I have troubles seeing the SSID again. Any ideas? Ive tried in linux and on my Mac.

G-Two commented 2 years ago

I erased my entire flash (including nvs) and loaded a fresh build from 8dee9c5 and think I see the issue that is causing the esp32 to go into a boot loop before wifi gets fully initialized. Let me test a solution real quick and I'll push a new commit.

G-Two commented 2 years ago

Ok, try pulling the latest commit (c35e0bf) and build/flash to your esp32. The bootloop should be fixed and you'll be able to connect any device to the Smoke X in its default AP mode. From there you can continue the rest of the configuration.

MikonosII commented 2 years ago

got it connected. now stuck at the Sync. My smoke x isn't getting the sync pulse from the lora. I do have the x4 wonder if that different?

G-Two commented 2 years ago

The web UI doesn't automatically refresh after a successful sync. Try refreshing your browser to see if the sync status changed. If not, I'll probably need your help to understand what the X4 sync message is though a more verbose debug build.

MikonosII commented 2 years ago

Nope no success. Let me know what you want me to try! I appreciate your help this project is awesome! I was going to try to write something but I found this before I started!

G-Two commented 2 years ago

Ok, if you pull the latest commit, the esp32 should dump the received raw bytes to the log by default now. You'll need to capture the esp32 logs with make monitor while you attempt the sync. This will display the bytes received on the sync channel (920 MHz). It's also possible the sync is succeeding, but I made an incorrect assumption of the X4 data packet which is causing a crash during the parsing. If you paste your logs, I should be able to figure it out. Also, if you happened to have already played around with the LoRa radio and know what the data format is already, I can just implement it quickly.

Here is the log of my X2 during a successful sync (the first two lines describe the sync packet):

I (37578) app_lora: Packet received - Size: 27 RSSI: -71, SNR: 8.000000
I (37578) app_lora: 000000,|dhHWl,160,32,69,54,
I (37578) smoke_x: Received sync message: 000000,|dhHWl,160,32,69,54,
I (37588) smoke_x: DeviceID set to: |dhHWl
I (37588) smoke_x: Frequency set to: 910500000 MHz
I (37598) app_lora: Setting radio parameters
I (37698) app_lora:   Frequency 910500000
I (37698) app_lora:   Bandwidth 125000
I (37698) app_lora:   Spreading Factor 9
I (37698) app_lora:   Transmit Power 12
I (37698) app_lora:   Coding Rate 5
I (37708) app_lora:   Sync Word 18
I (37708) app_lora:   Implicit Header 0
I (37718) app_lora:   CRC Enable 1
I (37718) app_lora: New radio parameters set
 f=910500000
 bw=125000
 sf=9
 tx_power=12
 cr=5
 sync=12
 impl_hdr=0
 crc_on=1

I (38728) smoke_x: Sending sync acknowledgement to transmitter
I (38908) app_lora: 15 bytes transmitted (|dhHWl,SUCCESS,)
I (39658) app_lora: Packet received - Size: 48 RSSI: -70, SNR: 11.000000
I (39658) app_lora: |dhHWl,30,1,1,0,766,1,200,32,0,766,1,160,32,0,0,
I (39668) smoke_x: Received data transmission from |dhHWl, saving config
I (39668) smoke_x: X2 DATA: |dhHWl,30,1,1,0,766,1,200,32,0,766,1,160,32,0,0,
I (39678) app_mqtt: Sending Home Assistant MQTT Device Discovery

I'm glad I finally have an X4 user to test and fix the code!

MikonosII commented 2 years ago

here's what I get... I tried it a couple of times with same result.

I (646) smoke_x: Device is not paired, waiting for sync on 0
I (2666) app_lora: Setting radio parameters
I (2766) app_lora:   Frequency 910500000
I (2766) app_lora:   Bandwidth 125000
I (2766) app_lora:   Spreading Factor 9
I (2766) app_lora:   Transmit Power 12
I (2766) app_lora:   Coding Rate 5
I (2776) app_lora:   Sync Word 18
I (2776) app_lora:   Implicit Header 0
I (2776) app_lora:   CRC Enable 1
I (2786) app_lora: LoRa module initialized
I (2786) smoke_x: Frequency set to: 920000000 MHz
I (2796) app_lora: Setting radio parameters
I (2796) app_lora:   Frequency 920000000
I (2806) app_lora:   Bandwidth 125000
I (2806) app_lora:   Spreading Factor 9
I (2816) app_lora:   Transmit Power 12
I (2816) app_lora:   Coding Rate 5
I (2826) app_lora:   Sync Word 18
I (2826) app_lora:   Implicit Header 0
I (2826) app_lora:   CRC Enable 1
I (2836) app_lora: New radio parameters set
 f=920000000
 bw=125000
 sf=9
 tx_power=12
 cr=5
 sync=12
 impl_hdr=0
 crc_on=1

I (2846) app_lora: Starting LoRa Rx
I (2866) wifi:wifi driver task: 3ffc6798, prio:23, stack:6656, core=0
I (2866) system_api: Base MAC address is not set
I (2866) system_api: read default base MAC address from EFUSE
I (2876) wifi:wifi firmware version: eb52264
I (2876) wifi:wifi certification version: v7.0
I (2876) wifi:config NVS flash: enabled
I (2876) wifi:config nano formating: disabled
I (2886) wifi:Init data frame dynamic rx buffer num: 32
I (2886) wifi:Init management frame dynamic rx buffer num: 32
I (2896) wifi:Init management short buffer num: 32
I (2896) wifi:Init dynamic tx buffer num: 32
I (2906) wifi:Init static rx buffer size: 1600
I (2906) wifi:Init static rx buffer num: 10
I (2916) wifi:Init dynamic rx buffer num: 32
I (2916) wifi_init: rx ba win: 6
I (2916) wifi_init: tcpip mbox: 32
I (2926) wifi_init: udp mbox: 6
I (2926) wifi_init: tcp mbox: 6
I (2926) wifi_init: tcp tx win: 5744
I (2936) wifi_init: tcp rx win: 5744
I (2936) wifi_init: tcp mss: 1440
I (2946) wifi_init: WiFi IRAM OP enabled
I (2946) wifi_init: WiFi RX IRAM OP enabled
I (2956) app_wifi: Wifi config SSID:
I (2956) app_wifi: Wifi config password:
I (2966) phy_init: phy_version 4670,719f9f6,Feb 18 2021,17:07:07
I (3066) wifi:mode : sta (7c:9e:bd:5b:bc:4c)
I (3066) wifi:enable tsf
I (3186) app_web_ui: Partition size: total: 956561, used: 268319
I (3186) app_web_ui: Starting HTTP Server
I (4046) wifi:new:<9,0>, old:<1,0>, ap:<255,255>, sta:<9,0>, prof:1
I (4896) wifi:state: init -> auth (b0)
I (4906) wifi:state: auth -> assoc (0)
I (5046) wifi:state: assoc -> run (10)
I (5186) wifi:connected with SSID, aid = 2, channel 9, BW20, bssid = 16:0c:6b:44:e1:6c
I (5196) wifi:security: WPA2-PSK, phy: bgn, rssi: -54
I (5196) wifi:pm start, type: 1

I (5236) wifi:AP's beacon interval = 112640 us, DTIM period = 3
W (5586) wifi:<ba-add>idx:0 (ifx:0, 16:0c:6b:44:e1:6c), tid:0, ssn:0, winSize:64
I (6146) smoke_x_main: IP address obtained
I (6146) esp_netif_handlers: sta ip: 192.168.1.68, mask: 255.255.255.0, gw: 192.168.1.1
G-Two commented 2 years ago

Can you try waiting a little bit longer after esp32 reset before attempting the sync? I'm not seeing any received bytes. The esp32 resets automatically when you invoke make monitor. The esp32 is parked on the sync frequency so there is no rush.

G-Two commented 2 years ago

Also, FYI, the logs display your WiFi creds within the first few seconds of booting. Sorry I forgot to warn you about that.

MikonosII commented 2 years ago

Thanks I saw that after posted. I've edited it. Given it a bit of time before putting the smoke x in to sync with nothing received in the log.

G-Two commented 2 years ago

Please confirm you're using the latest commit and have recompiled and reflashed (the latest commit should display all received bytes whether or not they are recognized smoke x packets). Otherwise we'll need to find some way to discover the sync frequency for the X4. Do you have an rtlsdr?

MikonosII commented 2 years ago

App "smoke-x" version: e258115

yep just fetched it again to verify, I'm not getting any hits in the log. I've got a hackrf and im looking at the spectrum, any specific frequency profiles im looking for?

G-Two commented 2 years ago

Set the hackrf in the 915 ISM band and put the smoke-x in sync mode. Make sure it stays in sync mode and watch the spectrum for a loud fairly long (half second or so) chirp spread spectrum burst. X2 syncs at 920.000 MHz every 5 seconds or so.

MikonosII commented 2 years ago

Its 915 MHz

G-Two commented 2 years ago

On the spectrum, the signal should appear to be a very narrow sinusoid that sweeps linearly over time with a span of 125kHz. The pattern of the sweep varies to represent the modulated bits. The sync burst is around 0.2 seconds in duration and repeats every 3 seconds. An example from my X2 is shown below:

bbq

If you can confirm your sync burst is similar to the above, it's probably just a software difference between the X2 and X4...let's hope that's the only one of significance! We can patch your code to get you running, but we'll eventually want the esp32 to monitor both 920 and 915 during the sync phase (i.e. dwelling on a freq for 1 second and then swapping).

G-Two commented 2 years ago

If you want to give 915MHz a try now, make the following change in https://github.com/G-Two/smoke-x-receiver/blob/e258115d41c3b349914bf4c16286d22ebede4793/main/smoke_x.c#L11 to:

#define SMOKE_X_SYNC_FREQ 915000000

Compile/flash and your esp32 will now monitor 915MHz for the sync burst.

If you could, please have make monitor running during the sync attempt and send me any logs that show the bytes received over LoRa. My X4 parsing is just a guess based on extrapolating the X2 data format, and I'd be surprised if there were no errors.

MikonosII commented 2 years ago

I will give it a shot tonight. I’ll try to get a IQ capture of the sync pulse and convert it to time domain… will take a bit of MATLAB work but I’ll see what it can come up with and let you know.

On Aug 26, 2022, at 08:27, Garrett @.***> wrote:

 If you want to give 915MHz a try now, make the following change in https://github.com/G-Two/smoke-x-receiver/blob/e258115d41c3b349914bf4c16286d22ebede4793/main/smoke_x.c#L11 to:

define SMOKE_X_SYNC_FREQ 915000000

Compile/flash and your esp32 will now monitor 915MHz for the sync burst.

If you could, please have make monitor running during the sync attempt and send me any logs that show the bytes received over LoRa. My X4 parsing is just a guess based on extrapolating the X4 data format, and I'd be surprised if there were no errors.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

MikonosII commented 2 years ago

Screen Shot 2022-08-26 at 6 33 51 PM

yep made the change but the LoRa logs didn't capture anything....

MikonosII commented 2 years ago
I (7524) app_lora: Packet received - Size: 71 RSSI: -57, SNR: 13.750000
I (7524) app_lora: 4oF_Ee,30,1,1,3,0,1,203,32,3,0,0,160,32,3,0,0,160,32,3,0,1,275,225,0,0,
I (7534) smoke_x: X4 DATA: 4oF_Ee,30,1,1,3,0,1,203,32,3,0,0,160,32,3,0,0,160,32,3,0,1,275,225,0,0,

used another esp32 and got it to provide the packet! On the website, only the first two probes display.

G-Two commented 2 years ago

Great, glad the receiver is working! This was with the code patched to sync on 915 MHz, correct?

I think I may have only implemented two probes on the web UI. I'm pretty sure the backend is parsing all the probes and passing their data to the web browser, but the vue component is just not graphing them for you on the front end.

MikonosII commented 2 years ago

Correct 915MHz for sync. What’s the best way to grab the data to store it? I know you said the http api get do you have an example?

On Aug 26, 2022, at 21:59, Garrett @.***> wrote:

 Great, glad the receiver is working! This was with the code patched to sync on 915 MHz, correct?

I think I may have only implemented two probes on the web UI. I'm pretty sure the backend is parsing all the probes and passing their data to the web browser, but the vue component is just not graphing them for you on the front end.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

G-Two commented 2 years ago

I designed it to work best with MQTT. The esp32 publishes the information from each received smoke-x data burst to a local MQTT broker I have running on my network. I have an MQTT subscriber (home assistant) that then receives the data and stores it in its local database. It also forwards the data to an influxDB instance for longer term storage and query.

Home Assistant really does all the magic when it comes to handling the data after the esp32 publishes it. But any MQTT client could work with it.

G-Two commented 2 years ago

You could also write a script to use the http interface to periodically get http://smoke_x/data and record the current temperatures from the JSON response.

G-Two commented 2 years ago

The original issue has been solved, so I'm going to close this. I opened up two new issues (#4 and #5) that describe the X4 problems that still remain.

G-Two commented 2 years ago

@MikonosII please give b4fe55c a try and let me know if all four probes show up in the web UI. Sync on 915 or 920 MHz should happen automatically now as well without the need to patch the code.

MikonosII commented 2 years ago

All good. Erased esp32 and reflashed and all synced up no issues! Thanks for the help and the app!

G-Two commented 2 years ago

Great! Are all 4 probes plotted?

MikonosII commented 2 years ago

Yep! No issues!

On Aug 30, 2022, at 20:28, Garrett @.***> wrote:

 Great! Are all 4 probes plotted?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.