Couldn’t agree more. We use Energizer Ultimate Lithiums in the ZigBee loggers that we ship and they just run and run.
And if you ever need to carry batteries as spares, these Enegizers are light and have a claimed shelf life of 20+ years.
Do you know if anyone has already changed the sketch, so that if there is a join error the unit goes to sleep then try again a bit later ?
I have got one unit which has got this error and it stayed stuck on the ON state with the blue LED for 3 days, which caused a 1V voltage drop. I had to reboot the unit to get it back online 
so I can’t really deploy the TTnode in the field as is.
I think it won’t happen, just look at the PR comments.
We’re facing on a “technical no way”, let me explain, for low power I needed to do changes on arduino-device-lib. Talking to RN2xx3 LoRa module with TheThingsNode or TheThingsUno is done with a hardware serial (UART) but the way it was coded if for a generic stream (not serial) without begin() methods needed.
My LowPower fix need to call this and I changed Stream to HardwareSerial for that. But it looks like arduino-device-lib can also be used with software serial (altsoftserial library) which has a different type (not HardwareSerial).
But at compile time library is unable to know what user will use (hardware serial or software) so the only solution I got is to define a constant to let the library which code to compile. I admit it’s not my favorite but I don’t have another solution, and looks like TTN team neither.
This solution (using stream instead of hardwareserial) makes sense to have majority devices compatible (which are not TTN one) without changing a line of code in the library. But on the other hand it impact the LowPower mode for TTN devices (which I repeat all use Hardware Serial).
So from my point of view TTN lib should match TTN devices and make them working as expected (ie no impact on battery life), and I think it’s what TTN backers and devices buyers want (let’s say an assumption of 90% of users?)
The other vision (not mine) is to make (again let’s say 10% and I’m sure I’m quite large?) others users happy and be able to use soft serial on other devices (not TTN one) without changing any line of code in the library, we impact severely battery life of 90% remaining users that bought TTN device and expecting as announced a battery life for one year.
As a reminder TheThingsNode battery life was between 2/3 weeks with a send every 5 minutes and now with fix it’s just ten time longer.
So if any code guru has a better solution let me know of course.
What about creating Boards for The Arduino Board Manager
And with precompiler check if it’s compiled for a TTN device
If it’s a TTN device use HardwareSerial otherwise use Stream … with precompiler
What do you think about that idea?
Absolutely, that’s what I suggested earlier (instead of selecting Sparkfun Board) in the PR, I’ve done by the past for custom boards and it’s not so complicated, just time consuming that I do not have 
I could fork the sparkfun Board and change the name?
Not enough, you need to have a repo, then a link to this repo to be able download boards definitions, that are compressed files with some MD5 calculation of the archive and some json description file.
Then TTN need to change documentation to this new procedure (add new boards and select them) and after that merge the modified PR 
We created now a device Library, which defines the constants “THINGS_NODE” and “THINGS_UNO”
https://raw.githubusercontent.com/samuel-puschacher/TTP_Arduino_Boards/master/package_thethingsproducts_index.json
So @Charles can use the Constant in the Librarys for the HardwareSerial and @johan is happy with the stream
4 Likes
The Board Manager URL has changed by wishes from @johan
The new link is: https://raw.githubusercontent.com/samuel-puschacher/arduino-boards/master/package_thethingsproducts_index.json
1 Like
The luminosity data from my node, since the code change, looks quite strange:
- If there is no direct sunlight the value is: 0
- if there is direct sunlight, the value can go up to: 1000
- in the night, when it should be 0, it is about: 8
I tested it with two nodes, same behaviour. Has anybody else noticed this?
@Charles could that have to to with the sleep mode, or gain setting?
plot of luminosity data from two days.
Do you light the led when reading luminosity ?
I don’t think it is related to the new sketch,
red and blue are oldskool december Cayenne sketches in a standard TTN node
purple is a TTN node with TTN sketch
Seems to me Cayenne code caps the reading at 1000
Hi, first I want to thanks for all the work.
I have started with the lib from Charles and the CayenneLPP sample.
I have modified the sample to get first moving detected with a timeout (MOVE_TIMEOUT) to not send a new moving if some stop occur during this timeout, the timeout is reset after each stop.
I have also add two params in the case of the node is Always Moving and stop.
So after MAX_NBSTART restart detected during MOVE_TIMEOUT time, the node will send data after the second timeout MOVE_INTERVAL has expired.
To do this I use watchdog because I can’t use timing objects during deep sleep mode.
I need to make minor change to the file TheThingsNode.cpp in the Arduino-node-lib.
Watchdog was not restarted after stop for example.
As I use ConfigInterval, to switch from Lora wake up to watchdog when move occurs, I need to add some change when node is connected to USB.
Here is my changes to the code.
2 Likes
Nice, thanks for your work.
I need to take a look into this. What about a Pull request so I can integrate your changes?
beginner in GitHub, I will try.
OK, it’s done