i just successfully installed/configured the LHT65 and try to send data via LIG16 to TTN because of no coverage at my location.
IF i press the ACT button the data as expected is shown in “live data” in the payload, but periodically sent data from LHT65 generates “Console: network error” and “Console: Stream reconnected”.
This is related to how your browser connection to the console view is running vs how actual device data is being handled or routed - if you look at the end data in what ever databse or dashboard you are using you should still see results, even for any period where your browser is ‘disconnected’ from the console stream.
The problem wrt browser/console view is usually down to stability of the viewing device’s (PC/Tablet/Phone?) internet connection to the console …if connection busy or device loaded with other tasks - I find more commeon where lots of browser tabs open and perhaps navigated away for a short time to other apps or programmes on device or if PC sleeps for a short time - e.g. whilst off grabbing coffee! - then these messages can be more common… e.g. have spent the last couple of days doing a few '00GB downloads and see this frequently across currently open 15-20 Console related tabs, through sheer pressure on the internet connection…
What application are you using it in? As temperature and humidity normally takes a long time to change. So setting it too fast you waste battery power and you need to take “Fair Usage Policy” of 30 seconds per day total airtime into consideration.
You will need to read the manual as how to change the reporting time.
i don’t understand that: “fair use policy”? why? my LHT65 is sending the data to MY GATEWAY (LIG16).
as i mentioned in the 1st post, i’ve no TTN coverage at my location. So the data goes via internet to TTN.
anyway, i cant find “time interval” in the configuration of my sensor/node/end device
Where it is processed and presented in the various console views and, if applicable, sent on to any Integrations you have set up…this server resource is free/funded by TTI for community use so besides limiting airtime (also a precious and shared community resource) the policy is designed to ensure no user abuses its availablility…30sec airtime/device is a useful way of ensuring TTN users do not over extend their welcome The fact you run your own GW is irrelevant in this context…indeed the same servers have to service your GW, schedule messages, ensure/enforce duty cycle policy etc…you wouldnt want people with handcuffs and a legal writ turning up at your premises saying ‘your’ GW is operating illegaly now would you?!
So imagine I roll out 8 nodes with a payload of 4 bytes in your area all TX at SF12 and a uplink every 10 seconds, your gateway have 8 channels.
The calculated air time is 1318.9ms per node, meaning I will take up 13.18% of your gateway time by just uplinks, this is on all 8 channels combined.
Now there are a few MAC downlinks that the NS needs to send to each node, with a downlink the gateway can only talk to one node at a time. While downlink is in progress the gateway can’t receive any node uplinks (it is deaf for this period). The MAC downlinks “manages” the nodes, the RF settings.
By this time we are now sitting anywhere between 13-15% of the gateway available time consumed with 8 nodes. This means you will only be able to roll out 50 nodes maximum on the gateway.
Now the other consideration is the NS, this is provided free of charge to us community. It manages the network and make sure that all is running smooth and your data reaches your application and forward to your integration.
Sure you can roll out your own NS, it is all on Github, but the FUP is for your protection, network protection and making LoRaWAN usable for you and me.