search

cyberman54 / ESP32-Paxcounter

Wifi & BLE driven passenger flow metering with cheap ESP32 boards
https://cyberman54.github.io/ESP32-Paxcounter/
Other
1.73k stars 405 forks source link

Add software serial and HAL file for ESPGateway #809

Closed squix78 closed 1 year ago

squix78 commented 3 years ago

This PR adds the ability to send the collected data over a software serial connection to another device. In addition, this PR also adds a HAL file for the ESPGateway which contains two ESP32-WROVER boards and external WiFi antennas. The first ESP32 will run this project to collect the data. It then sends it over serial lines to the second ESP32 which is connected over WiFi to a MQTT server. In concept it is very similar to the already implemented MQTT-over-Ethernet setup, except that a second ESP32 is used for the WiFi uplink.

The second ESP32 will have to be flashed with this project here: https://github.com/squix78/ESP32-Paxcounter-ESPGateway

I wasn't sure how and if I should add that simple code in this PR as well or if it was better to keep it separate from this project. My code currently creates a JSON string with the WiFi and BLE counters and sends this JSON string to the second "uplink" ESP32. This was very convenient since the JSON string can just be wrapped and forwarded to the MQTT broker. If you would prefer a more generic protocol for the serial line please let me know and I will adopt it.

Motivation The ESPGateway hardware seems like the perfect fit for this project: the external antennas extend the reach of the statistics collection to cover e.g. a bigger event or open space with less devices. The two ESP32 allow for independent uplink while still counting WiFi and BLE devices. In order to simplify the setup with would be great if you could accept this PR. BTW: kudos for the clean design of this project. It was very easy to add support for another device and communication protocol!

FlorianLudwig commented 3 years ago

Hi Daniel,

you created some interesting hardware there!

Regarding the uart protocol: I would actually prefer to see the same encoding over uart as on the other already present transports, like spi.

squix78 commented 3 years ago

Hi Florian I agree consistency is important in a project like this. I will see if I can understand the encoding and apply it to the UART protocol. What do you think about the code for the other ESP32? It is basically just reading the data from the UART line and sending it over MQTT. Should this stay in a separate project or is there a good way to integrate it into this project?

cyberman54 commented 3 years ago

Why not using only one ESP32 for this? Suspending wifi sniffing in regular intervals for a few seconds, then establishing the MQTT connection, send data and go on sniffing. Similar logic as already is implemented for sleep mode.

FlorianLudwig commented 3 years ago

Getting a bit off-topic here: I agree with @cyberman54 that the use case of having a second ESP just for sending the mqtt message is not worth it.

However I see use cases for having two ESP32-paxcounters combined:

So, overall I think it is hard to have a single protocol that covers all use cases for combining multiple ESPs.

squix78 commented 3 years ago

I was actually surprised that this "multiplexing" style wasn't already implemented and MQTT only available in combination with Ethernet. But since I had hardware that offered the possibility to keep scanning while being connected to MQTT that was my preferred solution. I'd love to contribute code to this wonderful project while taking good use of the ESPGateway hardware. I see three options: 1) I change my PR to use the encoding from the SPI slave (full duplex) as suggested by @FlorianLudwig 2) I try to create a new PR using the multiplexing approach described by @cyberman54. As suggested by @FlorianLudwig this would allow running one ESP32 for WiFi and the other one for BLE 3) I just keep my code as it is in a fork from your project

Before I spend too much time adapting the PR please let me know which makes the most sense to you and will have the highest chance of acceptance in the end...

cyberman54 commented 3 years ago

I think 2) would satisfy most user's needs.

squix78 commented 3 years ago

Ok, so let's sketch out solution 2 a bit. I have some questions:

Would be great if you could give me some pointers...

cyberman54 commented 3 years ago

My thoughts on your points:

  • MQTT/Wifi client: adapting the existing the mqtt client file and abstracting away the ethernet part vs. a new include file e.g. "wifiMqttClient.h" Which do you prefer?

I would prefer to abstract MQTT from network layer.

  • How would I temporarily disable the scanning? Is this done via RTC_runmode?

Don't touch RTC_runmode. Look at set_wifiscan()in rcommand.cpp as an example.

  • After the data is sent over WiFi, should I trigger a device reset/restart in order to get everything properly initialized?

Good question, since i did not develop a solution for this yet. Wifi is used by OTA, but for OTA i reboot the device first to ensure a clean baseline for the critical OTA process. I think we don't need this here. Set_Wifiscan() off/on should do the job.

cyberman54 commented 3 years ago

Regarding the ESP-Gateway: Unfortunately the LORAWAN part of this device is not compatible with paxcounter, since it's based on a Microchip RN2483 LORAWAN module. This has it's own MCU an LORAWAN stack, thus a completely different interface compared the "dumb" Semtech SX127x Lora chip, which the paxcounter project is designed for.

squix78 commented 3 years ago

So which chip/module would you suggest? If we see some interest it would be easy enough to adapt the hardware to be the "perfect" pax counter hardware: Nice enclosure, extended wifi and BLE range by using the external antenna. Maybe battery support? We are currently also working on a version with only one ESP32 but with ethernet connectivity. I currently don't quite understand for which use cases LoRaWAN would be preferred over WiFi backhaul. LoRaWAN has huge advantages in energy consumption over WiFi, but I think this is not that relevant with the pax counter, right? Running the pax counter far away from WiFi access points would be another reason for the LoRaWAN backhaul. Can you describe your perfect hardware and the most interesting use cases? I'd love to build this hardware!