I am moving my devices to v3 stack using the lorawan-stack-migrate scripts in github and it seems to be working fine. But I want to use the repository decoders and I can not find anywhere in the console where I can set the device type to for example a Dragino LHT65 LoRaWAN Temperature/Humidity Sensor.
Is it possible to set the device type/vendor on an imported device in the v3 console?
Did you add the device manually or did you do a “Import end devices”. On the “Add end device” button you get the option of setting the brand and model so v3 knows witch repo device encoder to use. Problem is that I can not set this when importing end devices and can not see any way of setting this after an import.
I am also looking for a solution to this. All I can see in the Payload formatters tab is the “Repository” option, but can’t specify anything further.
When you do an “Import end devices” in the v3 console with a json file from the lorawan-stack-migrate scripts, there seems to be no way of setting the devices brand and model so selecting the repo device encoder for the application does not work. I could always use a javascript decoder, but I would like to use a repo device encoder that works great when using the “Add end device” button.
I have run the migration tool to move Netvox devices over to v3. These are available in the repo. However I can’t find a way to set the device as you would under “Add end device”. I can specify “Repository” as the Uplink formatter, but nothing else.
I can create a device using the API and link it to a repository device so that it picks up the repro formatter. And I can grab the info from v2 to transfer over the details.
I tried using the migration tool and added in the repro device’s extra info and run in to some issues with the session information not being correctly formatted which I suspect may be a mis-alignment between the tool & the console or maybe just a bug. It seems odd that the migration tool doesn’t yield a JSON file that can be imported without modification. But having copied over the session info I could then import using the console. It may be unique to the device I happened to have data for.
So there are a number of ways this can be done. I’m working on a GUI tool that drives the migration and the main CLI apps as a general purpose visual migration interface. It’s easy enough to slot in the appropriate device repro once data has been pulled out of v2.
So I guess there are two things:
Debug the session info issue
and
Find out where people are with preferences for a user interface (CLI or basic GUI) and timescales.
All this said, I’m not entirely sure I can see the benefits of having a device migrated & attached to a repro device just to pick up the payload formatter - if you have many of a device, I’d be inclined to putting the formatter code in at application level so you have some control over the formatter. I’ve not yet established what happens if the repro is updated - whether there is any level of change control in the application server. So one other potential is to not link to the device repro entry but grab the formatter and set that up in the application.
I can see the utility of the device repro for new entered-by-hand devices but for bulk entry from a spreadsheet or database it seems a bit moot excepting there is an element of using the CLI to download device info but bizarrely, you can’t use the search function to search by brand or model number.
Thanks for your time looking into this. Wouldn’t it be simpler to just have the ability to search the repro payload formatter on the “End devices” level for imported devices on the console and leaving the migration tool as it is?
Probably - you’ll need to file an issue on GitHub for the stack and then await it to be triaged, allocated, a UI mockup created, design agreed, coded, tested, code review and integrated in to the code base …