Currently clients communicate with mower directly, this has several disadvantages:
REST-API and mower UI is hosted inside mower, this adds lots of code and complexity and takes up lots of precious Flash and RAM space that could be better user for other functionality.
Refreshing the browser on the client, or having several clients connected at once, puts a lot of stress on the low powered mower (ESP32). It almost resembles a DOS-attack and make the mower restart itself since it runs out of memory handling all the requests.
Human readable JSON responses from mower API takes up processing power, memory and WiFi bandwidth, still we want well documented and readable APIs.
We want more history from different sensors in the mower, and for a longer period of time, yet the small memory in the mower prevents us from having that.
WiFi is nice, but the weak PCB-antenna on the ESP-boards requires a lot of WiFi accesspoints to have a constant connection and coverage in your garden. Even the better Wrover-IB with external antenna won't have you connected all the time, unless you have a small garden.
......
A solution to this is to introduce a more powerful computer, placed in the docking station(?), that acts as a mediator/proxy for the mower towards the clients. The mower will report real-time information to docking station and clients will connect to the docking station instead. The advantages could be:
Lots of code could be stripped away from mower, saving memory and CPU cycles. (All WiFi, REST-API and MQTT stuff)
LoRa would be used to connect to docking station instead of WiFi. It will make sure that we always are connected to the docking station (LoRa has 20 Km range, few gardens are THAT big).
Communication between mower and docking station could be done over a small binary protocol that would save memory and bandwidth, like Protocol Buffers.
End user REST API could be more verbose and readable since its hosted on the more powerful computer (Raspberry Pi) in the docking station.
The docking station computer with access to much larger secondary storage could preserve history of sensor readings in a greater extent and for a far longer period of time.
Docking station could relay information to more 3rd-party systems that the current ESP-solution never could (because of memory constraints)
Parts of the mower UI resources (fonts, javascripts libraries, ...) are hosted on the Internet today since they won't in Flash-memory, could in the future be served from the docking station. This makes this a complete off-line (Internet) supported solution.
The same UI could in the future serve several mowers at once.
Currently clients communicate with mower directly, this has several disadvantages:
REST-API and mower UI is hosted inside mower, this adds lots of code and complexity and takes up lots of precious Flash and RAM space that could be better user for other functionality.
Refreshing the browser on the client, or having several clients connected at once, puts a lot of stress on the low powered mower (ESP32). It almost resembles a DOS-attack and make the mower restart itself since it runs out of memory handling all the requests.
Human readable JSON responses from mower API takes up processing power, memory and WiFi bandwidth, still we want well documented and readable APIs.
We want more history from different sensors in the mower, and for a longer period of time, yet the small memory in the mower prevents us from having that.
WiFi is nice, but the weak PCB-antenna on the ESP-boards requires a lot of WiFi accesspoints to have a constant connection and coverage in your garden. Even the better Wrover-IB with external antenna won't have you connected all the time, unless you have a small garden.
......
A solution to this is to introduce a more powerful computer, placed in the docking station(?), that acts as a mediator/proxy for the mower towards the clients. The mower will report real-time information to docking station and clients will connect to the docking station instead. The advantages could be:
Lots of code could be stripped away from mower, saving memory and CPU cycles. (All WiFi, REST-API and MQTT stuff)
LoRa would be used to connect to docking station instead of WiFi. It will make sure that we always are connected to the docking station (LoRa has 20 Km range, few gardens are THAT big).
Communication between mower and docking station could be done over a small binary protocol that would save memory and bandwidth, like Protocol Buffers.
End user REST API could be more verbose and readable since its hosted on the more powerful computer (Raspberry Pi) in the docking station.
The docking station computer with access to much larger secondary storage could preserve history of sensor readings in a greater extent and for a far longer period of time.
Docking station could relay information to more 3rd-party systems that the current ESP-solution never could (because of memory constraints)
Parts of the mower UI resources (fonts, javascripts libraries, ...) are hosted on the Internet today since they won't in Flash-memory, could in the future be served from the docking station. This makes this a complete off-line (Internet) supported solution.
The same UI could in the future serve several mowers at once.
https://github.com/nanopb/nanopb https://techtutorialsx.com/2018/10/19/esp32-esp8266-arduino-protocol-buffers/