Hi, I am a beekeeper and my hives are equipped with scales giving me precious information on the status of my hives.
Until last few days , I had 3 ABP devices on the V2 stack and a TTIG gateway using 3 different applications. Yesterday , I decided to migrate to V3 : Gateway and devices
I had no problem to update the TTIG gateway following the TTN indications. The 3 devices were continuing to transmit the information to V2 stack. Good job from TTN technicians : easy and well explained.
Then I decided to migrate my devices : one by one
first , i tried to avoid to reprogram the device and i have created a new device in V3 stack , with sames parameters and formater (CayenneLPP). Then I suppressed the device in Stack V2. I have been able to see, in Device Live Data, a message from my device arriving ONLY ONE TIME while I can see in the Gateway Live Data the messages from my device arriving every 5 minutes.
-then , thinking that the problem could occur due to the transfer of V2 device information, I decided to reprogram the device with the newly created device V3 information (still ABP mode). Exactly the same result : one message is arrived shortly after creation and nothing more . I still continue to see message arriving on the gateway every 5 minutes but not at device level
This message was properly decoded with CayenneLPP formater.
I continue to receive regularly the 2 other devices through the V2 server and my TTIG V3 gateway. But now , I cannot come back to V2 for this device …
I am sure that my bees would be very pleased to know that someone could help me to solve this situation. I have been through other similar topics but none gave me help.
Thanks for your help
Paul
Without knowing where in the world your Bees are it will be hard to know what settings may be going wrong. They will also need to tell you what the mystery device is and what firmware it is they put on it.
ABP comes with some setup requirements to make many legacy devices work nicely with the more standards compliant v3 stack. Any reason you can’t use OTAA?
TTIG bought at RS component successfully updated in claiming . 10 minutes after my 3 ABP devices were connected on V2 stack as before . Perfect !
Today I decided to migrate devices on V3 stack also …
I tried on 1 device without reprogramming it : I have been able to see one message arriving on Device console , that’s all . In the same time , on the Gateway Console , I can see massages arriving every 5 minutes from my device.
Then I decided to completely reprogram it as a new device on V3. Exactly teh same result : I an see it once only when it is still sending message periodicaly.
The 2 other are continuing to work fine on stack V2 through TTIG V3 gateway.
No idea on the problem currently.
If some one can help , it will appreciated , Thanks
Paul
Thanks Descartes for your fast reply.
My bees fly in France and are connected to the European server . The device is made of an arduino Nano, a Module LoRa RFM95 868MHz - SX 1276, and HX 711 for the scales and Arduino Nano SW. It runs perfectly on Stack V2 since many years (at least 16 months for me). It is still running on Stack V2 through migrated to V3 TTIG. It is an open source sw you can find on Beelogger.de
I suppose that the existing SW is compliant with the requirements as it works fine for months. Do you have a good reason to explain why I can have the message only once when I create the device when it repeated every 5 minutes and I can see it passing through the gateway without warning ?
What can I send you for you to check ?
Regarding my second post TTIG migration to V3, my intend was to confirm that migration was perfectly performed by the system and send congratulation to the team but such as other writers, I was also mentioning my problem. Sorry for the trouble I generated.
Anyway if you have a suggestion as now I am stuck on this device, I will also appreciate.
Regards
Dear Descartes, I have partially answer to your question in my previous post.
To your question :
ABP is much simpler to implement especially for beekeeper such as me which are not sw developper. There is no safety concern in both directions. The objective is to limit the power consumption because most of time there is no power source close to the hives.
But I am open to all suggestions .
Regards
Paul
I’ve got my German speaking Bumble Bee to quickly read the site and he says that he is concerned that only three frequencies are setup for the ABP mode, that ABP mode is being used when OTAA is highly recommended and that the version of LMIC is not the latest release from the Matt’s archive which is now discontinued.
My French Honey Bee says “Pfffft” and has gone to get a glass of wine.
I know LMIC rather well, it may be simpler if all the Queen Bees got together so we can debug this just once for all of you. Can you get Programmer Bee on to the forum?
I presume yes. It is functioning perfectly on V2 stack (still for 2 other identical devices except TTN parameter)) . Should I have to implement particular changes for V3 ?
My Bees are laughing very hard at this - very hard indeed. They have nodes in their garden that have been running for years on 2 x AA batteries without issue. OTAA is simpler because the server configures the device for you. ABP is harder because you will have to get the settings perfectly correct for the new v3 stack.
Your Bees were drunk on nectar - they have either followed the instructions for v3 or not - it’s a black or yellow issue. Just because it worked OK on v2 doesn’t mean your Bees can skip configuring the v3 devices properly. The v3 instructions, whilst not complete, are there for all Bees to read.
With today’s weather , they are surely not drunk with nectar currently …Anyway you are right but I check several times prior to disturb specialist . To be more accurate , I have strictly followed the tuto : https://beelogger.de/netzwerk/lora/lora-v3/
You will find familiar screens.
I have already informed “Programmer Bee” of my troubles but he is very busy ( summer is a hard period for bees ,as you know) . I am going to send him the link to this discussion.
My Bees are in the North of England - we do not have fresh running water so only drink mead.
I’ll update my “if you really must” ABP notes and a link to the latest version of what we call here Classic LMIC. You should ask Programmer Bee to act soon as it will save everyone a lot of effort if we can get the instructions sorted out.
This is the last version that Matt released but he has closed the archive now.
I used previous releases in the past and have used this version. The preferred version which is more compatible is this:
I’ve used up to 3.3.0 and am in the process of testing 4.0.0. It requires a Serious Geek Bee to set the library up to allow it to fit in to a Pro Mini / Nano and even then with the sensors you use it may not fit on the device, but let’s not worry about that now.
Wahoo ! I am a learning bee and I am not authorized to fly at this level …I will not attempt and transmit to the chief !
But do you have an idea where to check to find a solution to my situation. I have already suppressed the device in Stack V2 and cannot re-create a new one in V2 now .
Yes, here, by me and others that know enough to Bee dangerous. There isn’t some secret link to solve other peoples configuration issues as there are too many ways that the configurations can be done, properly or not quite right.
The ABP configuration on the Beelogger website is incomplete, so as I said above, I’ll update my ABP notes for LMIC and look at how OTAA may be setup.
In the meanwhile, if you search the forum you’ll find many many many many references to not deleting things from v2. But you can’t go back now, so you’ll have to go forward.
Apart from the scales, do you have any other sensors on your device?
Yes : voltages to folllow the battery level , Temperatures : inside and outside hive, humidity inside and outside , rain , bee counter
Not all sensors are implemented at each time. You have to configure your equipment according to what you want to know. You may implement up to 4 to 6 scales but there are some limitations (in terms of data volume) on TTN that prevent to send it too frequently ; in this case, it is longer to detect a swarm .
It is a compromise you have to establish .
Thanks for the interesting discussion, I am looking forward to your note and continue to look after the bug. I will keep you informed anyway
