Error "Unexpected Revision:" v3 to v4 tool

Decided to upgrade a V3 system (Ubuntu) to V4.

  • Made sure to update to latest v3 CS components. System still operational
  • Installed v4 complete and running
  • Ran chirpstack-v3-to-v4. No errors.
  • Stop and disable chirpstack-network-server and chirpstack-application-server
  • bring up web interface (:8080)
  • Nice, gateways and devices made it over. great.
  • Browsing to Device Profiles triggers the Error: Unexpected Revision:

    There are no profiles (that would make sense - new concept?)
  • Going into application/devices/ some_device/configuration, it show a device profile name from v3 system but clicking on it yields the above error.

Hopefully I can just add some device profiles, swap the profile assigned to each device and be good to go. I have other v4 systems working fine, this is the first time I have used the v3 to v4 tool.


I attempted to add a new Device profile. When I hit save, above error shows up and then I just see the spinning 4 dots:

Something must have failed in the v3 to v4 transition…

I just ran into this exact issue. would you mind sharing more about your environment? are you using any kind of proxy? What version of redis are you using? In my case, i’m using an nginx proxy and redis 7. I’m curious to know if we have any similar that might lead us to a solution.


The issue is in the database and ChirpStack is unable to map the value in the database to the Revision value ( Could it be that some of the device-profiles in the v3 database do not have this field set?

This value should be migrated (, my assumption is that it is not set (for whatever reason) in the v3 database and thus an empty value is being migrated.

A quickfix could be to run the following query (v4 database):

update device_profile set reg_params_revision = 'RP002-1.0.3' where reg_params_revision = '';

You then should see:


Or maybe a higher number than 1 indicating the rows that have been updated.

I found the issue in the “mode” column of the device table inside the network server database on the v3 side. looks be placing an “A” in that field if its blank, but I’m not sure thats working. I added this detail to the github repo issue as well.

I see, that fix was added but is not yet included in the latest release. I’ll build a new release now which should have the correct behavior.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.