Thanks again Nick.
Clear no need for confirmation of node message.
What I need is now modify my sketch to send readings from a bmp pressure temperature sensor and be able to read and store it in Chirpstack.
If I modify the first contact sketch and include the bmp readings, where can I access and store it in Chirpstack?
My ultimate goal is to implement a 14 node lorawan network with 7 sensors per node and store it in the internet, creating later a dashboard with grafana. All this is to be implemented in a lemon plantation in South east Spain in the coming 6 months as a company practice of my studies in technical school
I managed to send node/device info from node to AWS SNS.
But I think there was a problem RAK could solve, and I say as feedback:
DNS server for the RAK7243 is not configured with the configuration protocol in web.
I had to do so using Putty linux commands and then I got access to AWS SNS
Before that, I could ping from Putty SSH connection to 188.8.131.52, but not to google.es
Nevertheless, my RAK 7243 is not valid for AWS IOT Core, so I must stop here and get a new RAK 7258 to do so.
Is that a proper gateway for handelling 14 nodes with 7 sensors each, 8 mobile esp32 sensors to track tractors, and 40 one month seasonal nodes for sending 2-3 photos per day each of citrus pest traps? All nodes being lora ESP32?
I will need 1 RAK 7258 to try and 4 to 14 more, if I succeed, so Vladislav, If can get a discount for the company let me know how do it.
Thanks for all your help. You have clarified my way a lot, and make me realise how some things work, that without your help would have stopped me.
REally, thank you both
They both are, but if the sensors are outside, you could consider an outdoor gateway. Less than 70 devices would be no load at all for either, both of which could deal with 100’s if not 1000’s of devices.
What is it that stops the RAK7243 being valid for AWS IoT Core?
Given that most payloads are in the 20-50 byte range and there is an upper limit of ~222 bytes, you may not be able to pull a system together that sends pictures.
Yes Nick, but seems There could be a problem to smoothly run lambda procedures in AWS that way, and after trying to use AWS AI services in our year of data collecting to produce agricultural forecasts
It seems that with RAK wisgate Edge compatibles model that is easier to avoid problems.
How? If you put Basic Station on a gateway instead of using UDP, so that it has the correct software, how could that affect the downstream processing of data? All gateways running Basic Station present the same network protocol …
I don’t use Balena personally so I can’t say about the details of configuration - their website may be of use. They are well regarded by TTI as they had a main stage presentation at the TTS mini conference last Friday (27th May), one of the presenters was @xoseperez who works for a well known LoRaWAN IoT manufacturer based in China, so I’d expect he’d be able to help:
Create an account at balena.io (free up to 10 devices)
Click on the “Fork this fleet” button on the page linked above
Configure it (defaults will probably match your needs already) and click on “Create and deploy”
Click on “Add a device”, this will actually build an .img file you will have to burn on an SD card. You can use just Ethernet (DHCP is enabled by default) and optionally define a WiFi SSID and password if you want to. Finally click on the “Download BalenaOS” button at the bottom. Save the file.
Now use etcher or any other tool to burn the image to a new SD card, so you don’t overwrite the one that comes with the RAK product.
Plug it in the Raspberry and boot the board. In maybe 2-3 minutes a new device will appear on the Balena dashboard.
This should work using any RAK concentrator (RAK833, RAK2245, RAK2247, RAK2287 and soon the RAK5146) with a Raspberry Pi or any other SoC supported by Balena. This includes all RAK Development Gateways.