Test Adapter LoraWan v0.2.x GitHub/Latest

[Marc Berg]

@j_paul sagte in Test Adapter LoraWan v0.2.x GitHub/Latest:

verstehe nicht warum du da nochmals MQTT zwischen drin haben musst.

Nein, die MQTT Anbindung über Node Red würde dann natürlich komplett wegfallen. Trotzdem habe ich noch hundert andere Geschichten, die ich irgendwie automatisiere. Dafür bleibe ich bei Node Red.

[J_Paul]

@marc-berg
Da spricht absolut nichts dagegen, Go4It, no worries! Du kannst den LoRaWAN Adapter erstmal parallel zu deiner bisherigen Lösung einrichten und weiter NodeRed für deine Logiken nutzen, du könntest auch das "MQTT AddOn" noch dazwischen setzen, wäre aber unnötig, das ist, was ich sagen wollte.

[Marc Berg]

@j_paul sagte in Test Adapter LoraWan v0.2.x GitHub/Latest:

Go4It, no worries!

Schon angefangen und bei der ersten Aktion über einen Fehler gestolpert. Da hab' ich wohl ein Händchen für.

Issue erstellt.

[J_Paul]

@marc-berg
Ein Issue im Adapter zu erstellen, wäre gar nicht nötig gewesen, da wir hier auch zeitnah reagieren. Ich werde mir das gern morgen genauer ansehen, beim LT22222 ist, was die Zeitsteuerung angeht, auch eine Frage der Firmware Version.
Die zu dem Adapter mitgelieferten Konfigurationen sind als Beispiele zu verstehen. Vorschlag:
Du änderst in der Instanz bei den DL Konfigurationen den Namen des LT22222 in z.B. LT22222_A und änderst dort was immer dein Herz begehrt und das Device hergibt, trägst in deinem Device den Device Typ LT22222_A ein und bist ready2go.
Beim nächsten Adapter Start wird dann wieder (zusätzlich) die Konfiguration für das LT22222 erzeugt, welches du als Grundlage/Beispiel benutzen kannst, musst du aber nicht, da du dir jederzeit eigene DL Konfigurationen in der Instanz erstellen kannst. An einer Möglichkeit solche Geräte Konfigurationen zu exportieren/importieren arbeiten wir gerade.

Siehe Anleitung:

[Marc Berg]

@j_paul sagte in Test Adapter LoraWan v0.2.x GitHub/Latest:

, was die Zeitsteuerung angeht, auch eine Frage der Firmware Version.

Danke, das war mir nicht bewusst, dass es zwischen den Firmware-Versionen Unterschiede gibt.

Und jetzt habe ich es dank deiner Erklärung auch besser verstanden, wie das mit den Vorlagen/Konfigurationen abläuft.

[Marc Berg]

@j_paul sagte in Test Adapter LoraWan v0.2.x GitHub/Latest:

Vorschlag:
Du änderst in der Instanz bei den DL Konfigurationen den Namen des LT22222 in z.B. LT22222_A

Wenn ich so vorgehe, entsteht im Objektbaum unter "...downlink.control" ein "Merge" aus den Konfigurationen für LT22222 und LT22222_A (auch wenn ich den Objektbaum lösche). Ich muss die Konfiguration am Anfang anders (z.B. "XYZ_A") benennen, damit ich eine unabhängige Konfig erstellen kann. Ist das ein Feature (im Sinne von Vererbung von Einstellungen) oder Bug?

[Ben1983]

@marc-berg Feature im Sinne von Vererbung.
Alle sich in der config "LT22222" befindenden downlink, werden auch beim "LT22222_A" hinzugefügt.
So musst Du beim "LT22222_A" nur die abweichenden Parameter konfigurieren.

[J_Paul]

@marc-berg
Wenn Du FW Version ab 1.6 hast, kannst du (optional) 3 (doppel-) Byte für die Zeit schicken.
Dies wären dann max (FF FF FF) 16777215 ms, oder 4,66 Std.
Inwieweit das schalten eines mechanischen Relais im ms Bereich Sinn macht, musst Du selbst entscheiden, die DL Konfiguration sieht dann so aus:

[Marc Berg]

@ben1983 sagte in Test Adapter LoraWan v0.2.x GitHub/Latest:

Alle sich in der config "LT22222" befindenden downlink, werden auch beim "LT22222_A" hinzugefügt.
So musst Du beim "LT22222_A" nur die abweichenden Parameter konfigurieren.

Okay, ich wollte neben Änderungen auch Parameter löschen, was so dann nicht geht. Aber kein Problem, dann benenne ich das Device anders.

[Marc Berg]

@j_paul sagte in Test Adapter LoraWan v0.2.x GitHub/Latest:

Inwieweit das schalten eines mechanischen Relais im ms Bereich Sinn macht, musst Du selbst entscheiden,

Mein Garagentorantrieb benötigt einen kurzen Impuls (da reichen 250ms). Darum benötige ich weniger als 1 Sekunde.

[J_Paul]

@marc-berg
Dann reicht es, es A_LT22222 zu nennen

[J_Paul]

@marc-berg
250ms sollten mit oben gezeigten DL Konfiguration ja funktionieren, kannst ja mal testen und berichten

[Marc Berg]

@j_paul sagte in Test Adapter LoraWan v0.2.x GitHub/Latest:

kannst ja mal testen und berichten

Tor öffnet und schließt wie vorgesehen

Wobei es in diesem Fall wohl besser ist, eine "Button" Konfig draus zu machen. Der Zeitraum ist ja immer identisch.

[J_Paul]

@marc-berg
Ja klar, kannst auch einen Button anlegen, der dann Garagentor oder so heißt.
Danke für die Rückmeldung.
So steht der Nutzung über den Adapter nichts mehr im Wege, oder? Deine Logik über NodeRed kannst du ja direkt weiter nutzen.

[Marc Berg]

@j_paul sagte in Test Adapter LoraWan v0.2.x GitHub/Latest:

So steht der Nutzung über den Adapter nichts mehr im Wege, oder?

Doch, meine begrenzte Zeit.

Habe vorher noch Fragen:

• es gibt ein Topic: "v3/<application>@ttn/devices/<device>/down/sent", in welchem die effektiv an das Gerät gesendeten Daten drin stehen (nicht die in der Queue). Konkret die Eigenschaft "downlink_sent". Darauf benötige ich Zugriff, sehe aber im Objektbaum keinen DP, der diese Daten aufnimmt. Wie könnte ich das umsetzen?

Spoiler

{
	"end_device_ids": {
		"device_id": "ldds75",
		"application_ids": {
			"application_id": "sensoren-mb"
		},
		"dev_eui": "xxx88C182EBC2",
		"join_eui": "A000000000000101",
		"dev_addr": "xxxx075"
	},
	"correlation_ids": [
		"as:downlink:01JHT1J6SMFHG7SQP8DBSYGJH6",
		"gs:tx_ack:01JHT4DD3HVV03JAJ19MC3WXRE",
		"gs:uplink:01JHT4DCNDV47B87JMKHDHXHY3",
		"ns:transmission:01JHT4DD29GR8JV3RBAR1ZBPWM"
	],
	"received_at": "2025-01-17T12:39:38.355253902Z",
	"downlink_sent": {
		"session_key_id": "xxxxxxxbwOg8xzA==",
		"f_port": 1,
		"f_cnt": 659,
		"frm_payload": "AQADhA==",
		"decoded_payload": {
			"bytes": [
				1,
				0,
				3,
				132
			]
		},
		"priority": "NORMAL",
		"correlation_ids": [
			"as:downlink:01JHT1J6SMFHG7SQP8DBSYGJH6",
			"gs:tx_ack:01JHT4DD3HVV03JAJ19MC3WXRE",
			"gs:uplink:01JHT4DCNDV47B87JMKHDHXHY3",
			"ns:transmission:01JHT4DD29GR8JV3RBAR1ZBPWM"
		]
	}
}

• Könnt ihr bitte konfigurierbar machen, ob man die Notifications erhalten möchte oder nicht? Für die Meldungen, die dort erscheinen, gibt es aus meiner Sicht das Log.

Danke!

[J_Paul]

@marc-berg
Falls ich dich richtig verstanden habe, findest du dies in
lorawan.0.ApplicatioID.devices.DevEUIXXXXXX.downlink.raw.json

Um die Notification besser einzustellen zu können, kannst Du den Notification Adapter installieren. Falls ich es richtig verstanden habe, soll dies später in den Admin mit rein kommen.

[Marc Berg]

@j_paul sagte in Test Adapter LoraWan v0.2.x GitHub/Latest:

Falls ich dich richtig verstanden habe,
lorawan.0.ApplicatioID.devices.DevEUIXXXXXX.downlink.raw.json

Nein, dort stehen nur die "Queued" Messages drin, die zum Versenden anstehen. Diese wurden noch nicht unbedingt an das Device gesendet (weil es z.B. noch schläft).

Spoiler

{
	"end_device_ids": {
		"device_id": "ldds75",
		"application_ids": {
			"application_id": "sensoren-mb"
		},
		"dev_eui": "xxx2EBC2",
		"join_eui": "A000000000000101"
	},
	"correlation_ids": [
		"as:downlink:01JHT70SXPFKR7PMKHY4CCB69M"
	],
	"received_at": "2025-01-17T13:25:11.223375204Z",
	"downlink_queued": {
		"f_port": 1,
		"frm_payload": "AQAAWw==",
		"decoded_payload": {
			"bytes": [
				1,
				0,
				0,
				91
			]
		},
		"priority": "NORMAL",
		"correlation_ids": [
			"as:downlink:01JHT70SXPFKR7PMKHY4CCB69M"
		]
	}
}

[Marc Berg]

@j_paul

Ein weitere Frage in diesem Zusammenhang: Grundsätzlich kann man ja Downlink Messages nacheinander in die Queue stellen (control.push) oder aber die vorhandene Queue löschen und eine neue Message einstellen (control.replace). Wenn ich aber unter control.<Konfigurationselement> Daten zum Downlink einstelle, habe ich diese Option nicht, es wird immer an die vorhandene Queue angehangen. Richtig?

[J_Paul]

@marc-berg
Nur ist nicht richtig, wenn versendet wurde, findest du dort „downlink_sent“ (sorry fürs Bild, bin nicht am PC)

Stimmt, es wird immer angehängt, weil es in Chirpstack kein Replace gibt und wir es einheitlich haben wollten.

[Marc Berg]

@j_paul sagte in Test Adapter LoraWan v0.2.x GitHub/Latest:

Stimmt, es wird immer angehängt, weil es in Chirpstack kein Replace gibt und wir es einheitlich haben wollten.

Danke für deine Mühe. Ich muss jetzt erstmal überlegen, ob die Umstellung für mich sinnvoll ist, wenn ich am Ende für Up- und Downlinks doch wieder mit JSON hantieren muss.

Mein Usecase ist u.a. eine Minimierung des Akkuverbrauchs eines Zisternensensors bei gleichzeitig bester Messauflösung durch "intelligente" Steuerung der Mess- und Uploadintervalle. Dafür muss ich sicher wissen, welchen Intervall das Gerät zuletzt empfangen hat und ich muss in der Lage sein, den neuen zu setzenden Intervall innerhalb der "Sleep" Zeit mehrfach zu ändern.