Ankündigung

**johannes2912** · 19.02.2022, 00:47

Chirpstack Network Server:

Aufgabe:
Der Network Server ist als Zwischenschicht vor dem Application Server zuständig u.a. für die Authentifizierung, Paketplanung und Weiterleitung an den App Server.

Für Network Server und App Server benötigen wir eine PostgresDB.

Code:

apt install postgresql
systemctl start postgresql
systemctl enable postgresql
systemctl status postgresql
// chek if pg is running:
pg_isready

// jetzt erstellen wir einen User "chirpstack_ns" und die entsprechende DB dazu.
sudo -u postgres psql

create role chirpstack_ns with login password 'DB-PASSWORD';
create database chirpstack_ns with owner chirpstack_ns;
\q

// Test Connection
psql -h localhost -U chirpstack_ns -W chirpstack_ns

Nun erstellen wir noch einen mqtt User für den Net Server:

Code:

mosquitto_passwd /etc/mosquitto/pwfile chirp-net-server
systemctl reload mosquitto

Nun installieren wir den net Server sowie das benötigte redis:

Code:

apt install chirpstack-network-server redis-server
systemctl start redis
systemctl enable redis
systemctl status redis

vim /etc/chirpstack-network-server/chirpstack-network-server.toml

// edit section Postgres:
dsn="postgres://chirpstack_ns:DB-PASSWORD@localhost/chirpstack_ns?sslmode=disable"

// edit section mqtt:

// add username and password

username="chirp-net-server"

password="PASSWORD"

// edit timezone

timezone="Europe/Berlin"

// Start, enable and check Status
systemctl start chirpstack-network-server
systemctl enable chirpstack-network-server
systemctl status chirpstack-network-server

Sollten wir die Logs einsehen wollen geht das u.a. mit:

Code:

journalctl -f -n 100 -u chirpstack-network-server    <<<--- hier einfach den Dienstnamen verwenden. chirpstack-packet-multiplexer, etc...

**johannes2912** · 19.02.2022, 00:47

Chirpstack Application Server:

Aufgabe:
Übernimmt die Verwaltung der Lora Geräte, User, Mandanten, Applikationen, etc.
Stellt eine Weboberfläche zur Verfügung zur Konfiguration sowie u.a. eine RESTful API.

Auch hier benötigen wir wieder einen Postgres User und eine eigene DB:

Code:

sudo -u postgres psql

-- create the chirpstack_as user
create role chirpstack_as with login password 'DB-PASSWORD';

-- create the chirpstack_as database
create database chirpstack_as with owner chirpstack_as;

-- enable the trigram and hstore extensions
\c chirpstack_as
create extension pg_trgm;
create extension hstore;

-- exit the prompt
\q

// test connection

psql -h localhost -U chirpstack_as -W chirpstack_as

Ebenfalls benötigen wir einen mqtt user:

Code:

// add mqtt user for App Server
mosquitto_passwd /etc/mosquitto/pwfile chirp-app-server
systemctl reload mosquitto

Nun installieren wir den App Server:

Code:

apt-get install chirpstack-application-server

// Edit Config
vim /etc/chirpstack-application-server/chirpstack-application-server.toml

// edit section postgres:
dsn="postgres://chirpstack_as:DB-PASSWORD@localhost/chirpstack_as?sslmode=disable"

// edit section mqtt
// add username and password

username="chirp-app-server"
password="PASSWORD"

// Update JWT Secret

# JWT secret used for api authentication / authorization
# You could generate this by executing 'openssl rand -base64 32' for example

    jwt_secret="SECRET"

 
systemctl start chirpstack-application-server
systemctl enable chirpstack-application-server
systemctl status chirpstack-application-server

Nun sollten wir unter folgener Adresse ein Webinterface vorfinden:

Web-interface http://localhost:8080/
API http://localhost:8080/api

Default Username und Passwort für das WebUI sind: admin / admin

Im nächsten Schritt beginnen wir mit der Konfiguration im WEBUI.

**johannes2912** · 19.02.2022, 00:48

Konfiguration WEBUI Application Server

Da ich nicht auf alle Möglichkeiten und Einstellungen eingehe empfiehlt sich die Doku von Chirpstack:
https://www.chirpstack.io/applicatio.../applications/

Ich beschreibe hier nur mal grob die Grundlegenden Einstellungen. Es gibt hier unzählige Variationen.

Als erstes empfiehlt es sich das Passwort des Admin Users zu ändern.

Dazu nach erfolgter Anmeldung rechts oben auf Admin -> Change Passwort...

Hinzufügen des Network Servers

Im Menü links Network-Servers -> add

Network-server name *
Beliebigen Namen zur Identifizierung eures Netwerkservers eingeben. z.B: Localhost

Network-server server *
localhost:8000

Sonstige Einstellungen sind erstmal optional.

Erstellen eines Gateway Profils

Im Menü links Gateway-Profiles -> create

Name des Profils wählen. z.B. Lorix
Stats interval: 30 sec. <-- Das ist der Interval in dem der Lorix seine Heartbeats / Statistiken sendet
Enabled Channels: 0,1,2
Network Server : localhost <-- den soeben erstellten Network Server auswählen.

Erstellen eines Service Profils

Im Menü links Service-Profiles -> create

Name wählen
Network Server auswählen
check Add Gateway Metadata

Rest kann erstmal so bleiben.

Erstellen eines Geräte-Profils

Im Menü links Device-Profiles -> create

Es sollte für jeden Gerätetyp ein eigenes Profil erstellt werden, da die Payload Encoder und Decoder hier hinterlegt werden.

Beispiel für den Milesight WS101 Handsender:

Profile Name: Milesight-WS101
Network server: localhost auswählen
LoraWAN MAC Version in diesem Fall 1.0.3 <<-- in den technischen Dokumenten des jewiligen Sensors prüfen
LoraWAN Regional Parameter: A <<-- in den technischen Dokumenten des jewiligen Sensors prüfen
Default ADR algorithm
Uplink interval z.B. auf 86000 (24 Stunden) setzen.

Im Tab Join (OTAA/ABP):
Device supports OTAA (Over The AIR Activation) auswählen.

Im Tab Class B:
check Device supports Class B

Im Tab Codec:
Hier werden nun die Decoder definiert. Die Payload vom Handsender wird mittels der Decoder in ein verständliches Format gebracht.

Payload Codec: Custom JavaScript codec functions
Decode:

Code:

/**
* Payload Decoder for The Things Network
*
* Copyright 2021 Milesight IoT
*
* @product WS101
*/
function Decode(fPort, bytes) {
var decoded = {};

for (var i = 0; i < bytes.length; ) {
var channel_id = bytes[i++];
var channel_type = bytes[i++];
// BATTERY
if (channel_id === 0x01 && channel_type === 0x75) {
decoded.battery = bytes[i];
i += 1;
}
// PRESS STATE
else if (channel_id === 0xff && channel_type === 0x2e) {
switch (bytes[i]) {
case 1:
decoded.press = "short";
break;
case 2:
decoded.press = "long";
break;
case 3:
decoded.press = "double";
break;
default:
console.log("unsupported");
}
i += 1;
} else {
break;
}
}

return decoded;
}

Beispielscripts bekommt man bei guten Herstellern meist mitgeliefert.
z.B: Milesight: https://github.com/Milesight-IoT/SensorDecoders

Das Encode Script können wir erst mal default lassen. Das bräuchte man wenn Daten zurück zum Handsender gesendet werden sollen.

Hinzufügen eines Gateways:

In Menü links Gateways -> create

Name eueres Gateways z.B. Lorix
Beschreibung wählen...
Die Gateway ID (EUI) eintragen.
die entsprechenden Profile auswählen.

Rest kann erstmal so bleiben.

Erstellen der Applikation:

Im Menü links Applications -> create

Name, Beschreibung und Service Profil auswählen.
z.B. Name Edomi...

Anschließend können bereits die ersten Geräte gekoppelt werden.

**johannes2912** · 19.02.2022, 00:49

Handsender koppeln

Danach die Appikation öffnen und Geräte hinzufügen:

Bildschirmfoto 2022-02-19 um 10.43.58.png Bildschirmfoto 2022-02-19 um 10.44.58.png

Das vergeben der Tags ist optinal, kann jedoch später mal nützlich sein.

Nachdem das Gerät erstellt wurde müssen wir den beim Handsender mitgelieferten Application Key eingeben.

Bildschirmfoto 2022-02-19 um 10.48.25.png

Danach sollte man sofern der Handsender bereits läuft einen Join Request und danach einen Join Accept im Tab Device-Data sehen.

Ist der Handsender gekoppelt können wir fortfahren.

Die Milesight WS101 können per NFC mit der App Milesight Toolbox konfiguriert werden.
Hier kann u.a. der Buzzer aktiviert / deaktiviert werden, sowie der App Key geändert werden. uvm..

Nun sollte man per MQTT schon an die Daten kommen.

**johannes2912** · 19.02.2022, 00:49

Integration in Edomi

Für Edomi benötigen wir einen MQTT Subscribe Client sowie einen JSON Extractor.

Ich verwende hier folgende LBS:
MQTT Subscribe Client #19001054 http://service.knx-user-forum.de/?co...ad&id=19001054
JSON Extractor #19001208 http://service.knx-user-forum.de/?co...ad&id=19001208

Zuerst müssen wir jedoch noch ein mqtt User auf dem Chirpstack Server für Edomi erstellen:

Code:

// User Edomi für MQTT erstellen
mosquitto_passwd /etc/mosquitto/pwfile edomi
systemctl reload mosquitto

Danach die LBS herunterladen und in Edomi einlesen.

Hier nun eine Beispiel Logik für drei Handsender mit Unterscheidung zwischen kurzem, langem und doppeltem Tastendruck.

Bildschirmfoto 2022-02-19 um 11.04.42.png

**johannes2912** · 19.02.2022, 00:50

Fazit und sonstiges..

Das System läuft aktuell seit gut 3 Wochen ohne Probleme.
Reichweite ist mehr als ausreichend. Ca. 1km an Reichweite können wir hiermit bei uns erzielen.

Erweiterungen / Verbesserungen

- Durchgängige Überwachung aller Komponenten vom Gateway bis zu jeder Serverinstanz (prometheus -> https://www.chirpstack.io/network-se...cs/prometheus/
- Batteriemeldungen auswerten und bei zu gering -> Meldung (Die Handsender senden in einem bestimmten Interval ihren Batteriestand)
- mqtt / app Server verschlüsselung https / ssl
- Gatewayredundanz schaffen. Also ein zweites GW platzieren.
- Serverredundanz schaffen.
- Rückmeldungen an Handsender implementieren. Einige Handsender haben LEDs die man somit triggern könnte..
- Andere Sensoren integrieren: z.B. Parksensoren : https://iot-shop.de/shop/product/bo-...arksensor-4265
Oder GPS Tracker. Das wurde in einem anderen Thread hier schon einmal angesprochen. Wäre sicher auch sehr interessant.
- Lora D2D (device2device) testen (Es soll wohl eine Möglichkeit geben oder demnächst geben zwei Lora Geräte direkt zu koppeln. Somit wäre theoretisch der ganze Serverstack nicht mehr nötig. Wenn man einen Sender und einen Empfänger (Relais o.ä.) hätte. Habe dazu aber noch nichts überzeugendes gefunden..

Bitte beachtet dass es unzählige Möglichkeiten gibt das aufzubuen.
Man kann es über TTN beispielsweise viel einfacher realisieren.
Meine Lösung ist nur aus Gründen der Unabhängigkeit vom Internet so geworden...

Viel Spaß beim nachbauen und bei Fragen bitte einfach melden.

**DerSeppel** · 22.02.2022, 14:21

Wow. Sehr coole Idee.
Ich spiele schon länger mit dem Gedanken einen kleinen Controller mit LoRa ins Auto zu bauen um von weitem die Standheizung einschalten zu können. (z.B. Skipiste im Urlaub, bzw. Lüftung im Sommer).
In die andere Richtung hatte ich bisher nicht gedacht.
Cooles Projekt. Wirklich. Das GW ist auch preislich überschaubar.
Das wird wohl mein Herbst-Projekt....

**dirkie** · 25.11.2022, 19:22

Hallo johannes2912,
danke für die super detaillierte Anleitung. Ich habe mir grade den kleinen indoor Gateway geholt zum spielen und wollte deine Konfiguration nachbauen, da ich die lokale Variante inklusive splitting sehr gut finde.

Habe bei chirpstack gesehen das es eine Version 4 gibt. Hier scheint es den Multiplexer nicht mehr zu geben. Weißt du was da passiert ist oder ob es hierzu noch eine alternative gibt?

**johannes2912** · 25.11.2022, 22:57

Hallo dirkie
vielen Dank für das Lob. Freut mich wenn es dich inspiriert hat.

Den Packet Multiplexer bekommst du hier: https://github.com/brocaar/chirpstac...et-multiplexer

Du müsstest den multiplexer unabhängig vom Rest installieren können wenn ich mich nicht irre.
Er nimmt nur auf einem Port mittels Semtech UDP die Pakete an und schickt sie an ein oder mehrere Ziele weiter.

Laut Doku der V4 kann die Chirpstack Gateway Bridge weiterhin Pakete per Semtech UDP erhalten.
Von daher sollte es egal sein ob direkt vom Gateway oder via Multiplexer.

Ich bin noch auf V3, aber möchte zeitnah auf V4 migrieren.

**Gresse** · 12.12.2022, 21:06

Das Problem kommt mir bekannt vor ;-)
Wir haben es mit einer (selbst entwickelten) App gelöst, die bei Näherung ab einer bestimmten Position ein Signal an die (ohnehin vorhandene) Mobotix-Kamera schickt, die dann wiederum im Edomi eine Sequenz auslöst und nach dem Hoftor auch gleich das richtige Garagentor öffnet und nach kurzer Zeit beide wieder schließt.
Ja, man braucht dafür eine Internet-Verbindung, aber das war in den letzten 4 Jahren eigentlich kein echtes Problem. Dafür geht halt im Normalfall alles automatisch und die Reichweite ist unbegrenzt (ich habe auch schon vom Skiurlaub aus das Tor geöffnet).
Fallback ist - falls es mal irgendwo klemmt - die klassische Hörmann-Fernbedienung. Dann muss der Verkehr hinter mir halt mal ein paar Sekunden warten.
Alles noch ausbaufähig (der Torantrieb hat z.B. noch keine USV), aber dafür war es einigermaßen schnell realisierbar und sogar ohne zusätzliche Hardware-Anschaffung möglich.

**MVZ** · 12.12.2022, 23:33

Ich traue mich gar nicht zu fragen, aber was spricht gegen die Nutzung des Anruftriggers? Der Garage eine eigene Telefonnummer geben und falls bestimmte Nummern anrufen, geht das Tor auf. Damit bestehen auch keine Grenzen bei der Reichweite.
Wem die reine Nummernüberprüfung nicht sicher genug ist, kann bestimmt z. B. über FRITZ!Box, Callthrough und PIN die Sicherheit weiter erhöhen.

Autarkie ist dabei natürlich nicht gegeben. Ist der Strom weg, klappt weder das Telefon noch geht das Tor hoch!

Gibt es hierfür zu große Sicherheitsbedenken oder was spricht neben fehlender Autarkie gegen eine solche Lösung?

**Gresse** · 13.12.2022, 07:36

Ich hatte früher bei einem Garagentor eine Lösung via Telefonanruf (allerdings ohne KNX, aber aus Sicht des Fahrers macht das keinen Unterschied).
Durch die Positionsbestimmung auf dem Handy geht es jetzt aber vollautomatisch, das ist einfach nochmal ein Stück komfortabler als jedesmal anrufen zu müssen - zumal es auch Situationen gibt, in denen man gerade telefoniert, während man genau jetzt eigentlich das Tor anrufen müsste.
Nebenbei fällt bei mir die Telefonie schon häufiger aus als der gesamte Anschluss, nämlich ca. 1x pro Jahr, oder sie "zickt" (Verbindung kommt nicht zustande, man muss nochmal anrufen, ca. alle 3 Monate mal).
In der Praxis ist die häufigste "Fehlerquelle", dass ich gerade etwas an der Programmierung ändere und das Projekt im Edomi aktiviere, während jemand das Tor öffnen will... ;-)

**MVZ** · 13.12.2022, 07:59

Gleichzeitiges Telefonieren spricht natürlich dagegen.

Hatte eine solche Situation zum Glück nicht in den letzten Jahren. Wenn, telefoniere ich meistens auf dem beruflichen Handy und das private öffnet die Garage.

**gibsonrocker** · 13.12.2022, 08:57

Man kann auch mit Android und Tasker eine Geofencingfunktion bauen. Natürlich verknüpft mit der Bluetoothverbindung im Auto. Sonst geht das Tor auf wenn man zu Fuss kommt.

Ankündigung

Toröffner mit mehr als 100m Reichweite auf Basis von LoraWAN und Chirpstack

[Projekte] Toröffner mit mehr als 100m Reichweite auf Basis von LoraWAN und Chirpstack

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar