Skip to content

Releases: OS2iot/OS2iot-docker

v.1.5.2 - Updated Slow ADR Algorithm

18 Jun 11:39
02e4e27
Compare
Choose a tag to compare

What's Changed

Full Changelog: v.1.5.1...v.1.5.2

v.1.5.1 - Added min and max allowed datarate

05 Jun 12:03
Compare
Choose a tag to compare

Added min and max allowed datarate in Chirpstack configuration files

What's Changed

Full Changelog: v1.5.0...v.1.5.1

v1.5.0 - Upgrade to chirpstack v4

05 Mar 12:25
f2d9113
Compare
Choose a tag to compare

This release is intended to be used with OS2IoT-frontend v1.6.0 and OS2IoT-backend 1.6.0

What's Changed

Breaking changes

  • The Chirpstack version has been updated to v4, this breaks all communication between Chirpstack and the other resources.

New Contributors

Full Changelog: v1.4.0...v1.5.0

Migration guide

  1. Retrieve an RDB and AOF file from the Redis server being used, and place it locally on your PC. If things go wrong in the migration and Redis gets flushed, you'll have backup data in these files. Also, make a backup of the PostgreSQL database.

  2. Run the find-desync-devices.js (You need to enter connection information for the database before running it) file using the command: node find-desync-devices.js. You need to have Node.js installed to do this, as well as the pg package (can be installed using npm i -g pg). This is done to ensure that there are no LoRaWAN devices in OS2IoT that do not exist in Chirpstack. They wouldn't work as they are now anyway.

  3. This might output some deviceEUIs and names. If so, these devices need to be found in OS2IoT and deleted.

  4. Pull the latest release from the Docker repository (https://github.com/OS2iot/OS2IoT-docker) which ensures network server V3.16.8, application server V3.17.9, gateway-bridge V4.0.10, and the new Chirpstack V4.6.

  5. If your Postgres database is not managed by this repos docker-compose file, then a new database needs to be made with the following steps. This is where data will be migrated to.

    Database setup:
    Connect to the server with Azure Data Studio (download PostgreSQL extension).
    Run the following to create the database (Admin username should be without @<servername>)

    create role chirpstack with login password '<Password>';
    grant chirpstack TO "<admin username>";
    create database chirpstack with owner chirpstack;
    

    Switch to the new chirpstack database and run the following:

    create extension pg_trgm;
    create extension hstore;
    
  6. Publish the updated infrastructure with Docker or Helm. After publishing, you should be able to sign into the new Chirpstack with username: admin and pw: admin. If you are using Kubernetes, you can access Chirpstack by port forwarding the Chirpstack pod.

  7. Create an API key on the new Chirpstack instance. Go to the API Keys menu and create a new key. Copy the value, you won't be able to find it again.

  8. Insert it into your backend environment variables as CHIRPSTACK_API_KEY.

  9. Ensure that chirpstack-backend is exposed and update the environment variables CHIRPSTACK_HOSTNAME to the new exposed chirpstack-backend and CHIRPSTACK_PORT to the port used by chirpstack (Default is 8080).

  10. Navigate to the chirpstack-migration folder, located in the docker repo pulled in step 3.

  11. Expose your redis endpoint so it can be accessed externally (this should only be relevant if you are NOT using Docker).
    Port forward the Redis resource on Kubernetes. After it has been port forwarded, the resulting port can be used as the Redis endpoint (Localhost needs to be represented by 127.0.0.1 in the url).

    In your chirpstack.toml, chirpstack-application-server.toml, and chirpstack-network-server.toml, make sure the PostgreSQL URL is set up with the format:

    [postgresql]
    dsn="host=**HOST NAME** port=5432 dbname=chirpstack user=chirpstack password=**PASSWORD** sslmode=require" 
    

    In chirpstack.toml:

    [redis]
    servers=["redis://127.0.0.1:**PORT**"]
    

    In application and network-server.toml (Notice url instead of servers)

    [redis]
    url="redis://127.0.0.1:**PORT**"
    

    and Mosquitto server with the format:

    server="tcp://mosquitto-svc:1883"
    
  12. Perform the migration using the following command. You must be in the chirpstack-migration folder:

    ./chirpstack-v3-to-v4 --as-config-file **PATH/TO/CHIRPSTACK-APPLICATION-SERVER.TOML** --cs-config-file **PATH/TO/CHIRPSTACK.TOML** --ns-config-file **PATH/TO/CHIRPSTACK-NETWORK-SERVER.TOML** --drop-tenants-and-users
    
  13. Verify that devices, profiles, and gateways have been transferred to your new Chirpstack, and verify that data is coming in to gateways and devices.

  14. Change your redis endpoint back to not being accessible (remove port forwarding). That means you need to reverse what you did in step 7. Also, update chirpstack.toml to have the original redis URL again.

  15. Publish backend and frontend to your OS2IoT instance and verify via the OS2IoT portal that things are working as expected, and that you can see data coming in to devices and gateways.

  16. The data format has changed, thus payload decoders need to be updated. Before you update them, you should copy all your payload decoders and save them locally, so you have something to compare with, if payload decoders don't work after running the fix script. Be aware that the fix script will only handle payload decoders used in relation to LoRaWAN-devices, since the data format change is not relevant for other device types.

    Run the rename-payload-decoders script using the command node ./rename-payload-decoders.js. If all goes well, the console will print Decoders updated successfully.

    The following properties have been updated:

    applicationID -> deviceInfo.applicationId
    applicationName -> deviceInfo.applicationName
    deviceName -> deviceInfo.deviceName
    devEUI -> deviceInfo.devEui
    deviceProfileID -> deviceInfo.deviceProfileId
    deviceProfileName -> deviceInfo.deviceProfileName
    rxInfo.loRaSNR -> rxInfo.snr
    rxInfo.time -> rxInfo.nsTime
    rxInfo.gatewayID -> rxInfo.gatewayId
    rxInfo.uplinkID -> rxInfo.uplinkId
    txInfo.loRaModulationInfo -> txInfo.modulation.lora
    confirmedUplink -> confirmed
    publishedAt -> time
    tags -> deviceInfo.tags
    rxInfo.timeSinceGPSEpoch -> rxInfo.timeSinceGpsEpoch
    

    The following properties cannot be moved as they have not been readily found in new data packets from Chirpstack.

    rxInfo.accuracy
    rxInfo.rfChain
    rxInfo.board
    rxInfo.antenna
    rxInfo.fineTimestampType
    txInfo.modulation
    txInfo.polarizationInversion
    
  17. In Chirpstack version 4, device profiles cannot display the default ADR algorithm if nothing is set in the database. Therefore, a script needs to be executed to insert the value "default" wherever an ADR algorithm is not set.
    Run the file "rename-adr-algorithm.js" using the command node rename-adr-algorithm.js.
    If everything goes well, the console will print the device profiles that have been updated.

  18. Once it is verified that data has come over, and that data is coming in to your gateway and devices, you should move your old chirpstack-network-server and chirpstack-application-server to a legacy folder, so it is not published again in future updates. Additionally, the network server and application server should be removed so they do not access Redis since they are no longer used.

v1.4.0 - MQTT device support

05 Jun 09:02
Compare
Choose a tag to compare

This release is intended to be used with backend and frontend v1.5.0

What's Changed

  • Added a tls Mosquitto mqtt broker for receiving mqtt data
  • docker and helm updates. Input values has to be set from the user. by @augusthjerrild in #13

Breaking changes

  • There has been introduced some new settings that needs to be set for the hosting to work for MQTT support, more can be read in the docs Installation guide

Full Changelog: v.1.3.0...v1.4.0

v.1.3.0 - Support for Slow ADR Algorithm

17 Nov 11:15
Compare
Choose a tag to compare

What's Changed

  • Added custom adr algorithm for slow data-rate correction by @MStenkaer in #12

New Contributors

Full Changelog: v.1.2.1...v.1.3.0

v.1.2.0 - New User Management, MQTT DataTarget, Improved LoRaWAN Monitoring, General fixes

13 Jun 10:28
Compare
Choose a tag to compare

What's Changed

Full Changelog: v.1.1.0...v1.2.0

v.1.2.1 - Number of rows per table set to 25

13 Jun 11:45
Compare
Choose a tag to compare

Minor update setting default number of rows to 25 as an environment variable.

What's Changed

Full Changelog: v1.2.0...v.1.2.1

v.1.1.0 - Simulator added

23 Feb 11:10
bb00ae8
Compare
Choose a tag to compare

What's Changed

LoRaWAN simulator (https://github.com/UniCT-ARSLab/LWN-Simulator.git) has been added as a docker container.
Using this, it is now easy to simulate real LoRaWAN devices.

Full Changelog: v.1.0.1...v.1.1.0

v.1.0.1

12 Nov 14:05
Compare
Choose a tag to compare

Covers the first round of closed issues and pull requests. Compatible with frontend and backend v.1.0.1

What's Changed

New Contributors

Full Changelog: v.1.0.0...v.1.0.1

v.1.0.0

12 Nov 09:22
e6cedd3
Compare
Choose a tag to compare

First release of OS2iot docker

Contributors

Full Changelog: https://github.com/OS2iot/OS2IoT-docker/commits/v.1.0.0