Transmit status every 20 minutes (Unconfirmed Uplink with ADR, running at SF7)
Disable Alarm
Problem: Every time the switch/detection gets actuated the 20-minute timer starts again from zero. So if the switch gets actuated every 10 minutes you will never receive a message. The event counter does get updated correctly though. 20 minutes after the last “event” a message with the correct event-count value will be sent.
I have not tested this on the LDS01 but would assume it has the same issue?
Correct.
Thanks for the answer Edwin, but you misunderstood my post.
I would still expect the device to report in the set TransmitTimeInterval even when the Alarm is disabled. (TransmitTimeInterval can be set with downlink on Port2 with 0x01 nn nn )
Another example: I disable the alarms. Therefore if switch is activated no message will be sent. That’s ok. I now set the TransmitTimeInterval to 1 hour, so I expect the device to send a status every hour.
This works great as long as there are no switch events. In that case the device will send a message every hour.
So let’s say this happens every full hour. Like 1pm, 2pm 3pm and so on.
Now let’s say the last message was sent at 7pm.
At 7:58pm there is a switch activation.
Since alarm is disabled no message will be sent at 7:58pm. That’s expected.
Now you would think that the next time-based message would be sent at 8pm (one hour after 7pm).
But this is not the case. The alarm event at 7:58pm resets the one-hour-timer and, if no other switch event occurs, the next time based message will now be sent at 8:58pm instead of 8pm.
And if switch events occur like let’s say every 40 minutes, then our one hour TransmitTimeInterval message would never be sent, since every switch event would reset our TransmitTimeInterval timer before it expires.
Maybe, but we like to keep the sarcasm about firmware updates vs battery holders to a minimum, there are many people working hard on migration issues and you do have a workaround by setting the Rx1 to 1s in the interim.
As a moderator it is one of Nick’s tasks is to help keep threads focussed and avoid duplicate postings and spreading of effort - you would be suprised how much time gets spend dealing with such duplicate posts, managing the various posts, and how much effort from the community is taken with dealing with dilution of effort. Mods are volunteers and dont get paid to help manage matters but give their time freely for the benefit of all… and, whilst judgement has to be applied and is subject to perspective - hence contentious issues get discussed and reviewed by the team of mods to ensure fair play and correct application of policy, there is no deliberate sensorship. No doubt we will be advised by Edwin and the team once Dragino have firmware released and ready to go supporting V3 for all applicable devices… in the meantime Jac made a valid observation and as stated there is a workaround in the interim…
Knowing Edwin and the team I’m sure they will be working hard on the task, and also they will not release until confident of the release quality with support of decent level of testing. In the couple of months since this was raised Edwin confirm problem with commitment to update I know the TTS(CE) has seen several upgrades and improvements, including as recently as last Monday, as system evolves to greater features, capabilities and stability, so likely they are developing and testing against what is a moving target They will be motivated to deliver, but will want to deliver well I’m sure, after all the TTN community and TTS generally in all its hosted or private deployment forms represents a signifiacnt market segment and opportunity for Dragino, as it does for many of the other manufacturers servicing the LoRaWAN ecosystem. Like you, I have multiple Dragino devices and I know I just have to be patient, esp as planning to take on and deploy more under V3 when ready
That is my conclusion based on the information I have, which has not been confirmed not denied by Dragino yet. I was about to test but the tone of your messages puts me off spending another second on the subject. Anyone genuinely interested in answers can contact me by PM.
They will be motivated to deliver, but will want to deliver well I’m sure, after all the TTN community and TTS generally in all its hosted or private deployment forms represents a signifiacnt market segment and opportunity for Dragino, as it does for many of the other manufacturers servicing the LoRaWAN ecosystem. Like you, I have multiple Dragino devices and I know I just have to be patient, esp as planning to take on and deploy more under V3 when ready 