struggling with similar issue.... nodemcu 1.0 (esp8266EX) - connected on com6, but back of board says connect at 9600.
serial monitor at 9600 can display correct messages at boot.. no AT command response, but then when i upload some simple code i get the following:
Crystal is 26MHz
Configuring flash size...
Traceback (most recent call last):
File "C:\Users\jph1l\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\3.0.1/tools/upload.py", line 66, in <module>
File "C:/Users/jph1l/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/3.0.1/tools/esptool\esptool.py", line 3599, in main
File "C:/Users/jph1l/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/3.0.1/tools/esptool\esptool.py", line 2848, in detect_flash_size
flash_id = esp.flash_id()
File "C:/Users/jph1l/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/3.0.1/tools/esptool\esptool.py", line 688, in flash_id
return self.run_spiflash_command(SPIFLASH_RDID, b"", 24)
File "C:/Users/jph1l/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/3.0.1/tools/esptool\esptool.py", line 948, in run_spiflash_command
old_spi_usr = self.read_reg(SPI_USR_REG)
File "C:/Users/jph1l/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/3.0.1/tools/esptool\esptool.py", line 562, in read_reg
val, data = self.command(self.ESP_READ_REG, struct.pack('<I', addr))
File "C:/Users/jph1l/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/3.0.1/tools/esptool\esptool.py", line 386, in command
p = self.read()
File "C:/Users/jph1l/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/3.0.1/tools/esptool\esptool.py", line 331, in read
File "C:/Users/jph1l/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/3.0.1/tools/esptool\esptool.py", line 2636, in slip_reader
raise FatalError("Timed out waiting for packet %s" % waiting_for)
esptool.FatalError: Timed out waiting for packet header
esptool.FatalError: Timed out waiting for packet header
any ideas - change usb cable, ports, confirmed the com not used elsewhere... any ideas?
FYI - the blue LED on the NodeMCU does flash once you start the upload.. flash a couple of times then stops.
Pressing the FLASH and holding down before the upload command or once it tries to connect etc there is no difference.
@TheoL I do agree with your experience with the Ikea remote. I also have them connected to the coordinator and are draining quite quickly.
Many manufacturers still charge a lot for Zigbee devices.
Making your own Zigbee devices require a lot of learning. I have tried and failed (not as much dedication as it needed). The WiFi route seemed closer since I already had the network setup.
Convenience and mesh availability won in my case.
Is Thread a future possibility for MySensors?
Again, talking from my very individual situation. I can see running over someone else's mesh would make MySensors a more attractive option.
I think you need to post a clear drawing or photos of the setup and the code you are using.
I donlt know what you mean by "connecting the current in series" nor what "AC regulator" you are using or what "thermal serial currenr" is.
This is possible yes. In fact I used this setup before, but in the end I stopped using it and separated the gateway from the P1 handling. I noticed very high rates of CRC failures, since the mysensors stuff takes time to handle also, and during this time characters from the P1 port got lost. I should say though that after I separated these, I did some improvements on the P1 decoding which may give better results when it is being used together with the gateway. I didn't send it to mysensors but directly to mqtt.
Tasmota is also able to handle the P1 stream by the way, with a template. https://tasmota.github.io/docs/Smart-Meter-Interface/
But back on topic - that device looks pretty cool, if it does half of what it claims. I'm a little tempted, even at my own cost. I won't, but if my insurance company ever offers it, I'll jump at it.
Yes, it's a little 1984. But I also already signed up for an app with my car insurance that monitors my driving. It doesn't have any hardware, just GPS and accelerometer from my phone, but it doesn't cost me anything other than some power and I guess privacy. But it saves me something like 15% and I don't have to do anything. I guess if I ever really care about it watching me go somewhere I can disable it for that amount of time.
A little weird what we're willing to put up with, I guess. Though I also like the fact that with a record of how I drive, if there's ever an accident, it might also be possible to subpoena the data in my defense if really necessary. Or maybe that's just what I tell myself to help justify it?
@NeverDie said in Looks as though ESP-NOW is finally working...:
Anyhow, sleep current for ESP8266 and ESP32, the last time I checked anyway, was still kinda high, but I do wonder what the startup time would be if an ESP module were kept in a totally turned-off state until it was needed. Perhaps the higher transmit speed that is possible with a wifi PHY would allow high power to be used only briefly (~250ms in the example in the video), and so maybe total power consumed from the start of wake-up through the transmission may yet turn out to be a win?
Power consumption in deep sleep is really low if using a barebone ESP32-WROOM or WROVER. I did a project in 2020 before the lockdown using a custom ESP32-WROOM in a Soil Moisture capactive sensor and took some measurements to check the power consumptions in each state. The results were:
With delay (idle): 39,29 mA in the 3V3 input from FTDI adapter.
In deep sleep: 5,4 uA in the 3V3 input from FTDI adapter.
While transmiting (ESP-NOW protocol) the power spike was huge, an average of 200mA, and I think the peak demand was even higher (400 mA?)
With 600mAh LiFePo4 Batteries, the expected duration is aprox. 5 months. No Regulator needed when using LiFePo4. If using regular LiPo or Li-Ion batteries, careful selection of the regulator is crucial because of the spike while transmiting if the regulator is not capable enough or close to the 3V3 pin of the module, a Brownout is quite probable.
This duration (5 months) is calculated assuming that the processor wakes every 15 min to take a sample of the soil for 2 seconds. If the difference between the measured content and last reported value is less than 5% (aprox. Error of the probe), the value is not sent to the controller (no wifi used). It is estimated that 4 measurements per day are sent. If there is no different in moisture content in a days cycle (every 96 wakeups) the sensor reports the measured value along with voltage. Voltage is sent in every moisture report. It is not considered important to send more frequent updates of voltages, LiFePo4 have a flat discharge curve.
The most impacting measure in extending the battery life in this design was the On-Time of the sensor necessary to stabilize the output (feeding the capacitive soil moisture sensor). It is observed that reducing the On-Time has an impact in the measured output. In the sensor, whenever I woke the sensor from deep-sleep I activate a mosfet to drive the feed to the capacitive soil moisture sensor and wait for 2,4 seconds.. that is the part of the cycle that is more critical to battery life.
The time to transmit the data was on average 80 miliseconds (from ESPNOW initialization to data sent). Here is a dump from the serial monitor to check this duration:
16:21:19.694 > rst:0x5 (DEEPSLEEP_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
16:21:19.694 > configsip: 0, SPIWP:0xee
16:21:19.694 > clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
16:21:19.694 > mode:DIO, clock div:2
16:21:19.694 > load:0x3fff0018,len:4
16:21:19.694 > load:0x3fff001c,len:1044
16:21:19.694 > load:0x40078000,len:8896
16:21:19.694 > load:0x40080400,len:5828
16:21:19.694 > entry 0x400806ac
16:21:19.694 > Boot count: 8
16:21:19.982 > Moisture level (pre): 722.62
16:21:20.853 > Moisture level %: 0.00
16:21:20.853 > Voltage level: 2389.50
16:21:20.853 > Voltage Battery: 3.34
16:21:20.853 > Startig Wifi Now...
16:21:20.853 > Wifi Setup complete.
16:21:20.934 > Send success
There is a possibility to further reduce power consumption. Yo can manipulate pint status and read the ADC while maintaing the main cores in deep sleep by using the low power co-procesor. This coprocesor would check if the value has changed since the last transmission and wake the main processor if it is necessary.
And in relation to ESPNOW and MySensors, I used a TTGO-Lora board with ESP32 and LORA transceiver as the MySensors and ESPNOW gateway. The gateway processed the value from the sensors received by the ESP-NOW "custom" protocol to MySensors... the controller (Openhab) was only aware of sensors atached to the
ESP-NOW Sensor --> TTGO-Lora (Translates from ESP-NOW to MySensor Message) --> Openhab
I did also a proof of concept with a Repeter-translator from ESP-NOW to Mysensors:
ESP-NOW Sensor --> TTGO-Lora (Translates from ESP-NOW to MySensor Message) --> TTGO-Lora (receives MySensor Messages) --> Openhab
The ESP-Now MySensors gateway sketch was not very elegant but worked.
The next step would be using ESPNOW as a new MySensor Protocol... to do it myself I should spent quite some time learning how MySensor Code works.. I have tryed in the past but never have the change to work enough time to understand it fully.
If this transport is supported, I see quite an advante of ESP32 vs NRF5284, both would use the 2,4 GHz band, but ESP32 transmission power is +20dbm (vs +8 dbm for the NRF5284 if I am not mistaken), also, a barebone ESP32-WROOM price is 2 € and is not hard to hand-solder... to that you have to add the components to design a custom board but overall quite competitive.
Custom board (first try.. a cable to fix some design errors . )
This thread is really good, kind of addicting to scroll all time.
Only problem though is the way it is structured. Its really hard to find the same post twice.
Maybe the admins should consider having a separate section for this !!>?