WisBlock API V2
AT command parsing and default fPort changes
 |  |  |  |  |
|---|
Diese Arduino -Bibliothek für rakwireless Wisblock -Kernmodule kümmert sich um einen geringen Stromverbrauch und kümmert sich um alle Lora P2P, Lorawan, Ble, bei Befehlsfunktionen. Sie können sich auf Ihre Anwendung konzentrieren und den Rest der API überlassen. Es wird als Begleiter der SX126X-Herduino Lorawan Library gemacht
Es erfordert einige Überdenken über Arduino -Anwendungen, da Sie keine setup() oder loop() -Funktion haben. Stattdessen ist alles ereignisgesteuert. Die MCU schläft, bis sie Maßnahmen ergreifen muss. Dies kann ein Lorawan -Ereignis sein, ein auf den USB -Anschluss oder ein Anwendungsereignis empfangener Befehl, z. B. ein Interrupt von einem Sensor.
Dieser Ansatz erleichtert das Erstellen von Anwendungen, die für den Nutzungsverbrauch mit geringem Stromverbrauch entwickelt wurden. Während des Schlafes verbrauchen die Wisblock -Basis + Wisblock Core RAK4631 nur 40UA.
Darüber hinaus bietet die API zwei Optionen zum Einrichten von Lora P2P / Lorawan-Einstellungen, ohne dass sie in die Quellcodes fest codieren müssen.
V2 der Bibliothek änderte das AN -Befehlsformat, um mit RUI3 bei Befehlen kompatibel zu sein. Bitte überprüfen Sie das AN -Befehlshandbuch für RUI3 auf Unterschiede.
V2 Release unterstützt nur das Rakwireless Wisblock RAK4631 -Kernmodul
Die Unterstützung für RAK11310 und RAK1200 könnten in Zukunft hinzugefügt werden
Die API bearbeitet alles von setup() , loop() , Lorawan -Initialisierung, Lorawan -Ereignishandhabung, BLE -Initialisierung, BLE -Ereignissen zur AT -Befehlsschnittstelle.
BEMERKUNG!
Die Benutzeranwendung darf nicht die Funktionen setup() und loop() !
Die Benutzeranwendung verfügt über zwei Initialisierungsfunktionen, eine wird zu Beginn von setup() aufgerufen, die andere am Ende. Die anderen Funktionen sind Ereignisrückrufe, die von loop() aufgerufen werden. Es ist möglich, benutzerdefinierte Ereignisse (wie Interrupts von einem Sensor) zu definieren.
Sensor -Lesung, Aktuatorsteuerung oder andere Anwendungsaufgaben werden in app_event_handler() behandelt. app_event_handler() wird häufig aufgerufen, die Zeit zwischen Aufrufen wird durch die Anwendung definiert. Zusätzlich wird app_event_handler() auf benutzerdefinierte Ereignisse aufgerufen.
ble_data_handler() wird von loop() auf Ble -Ereignisse (BLE UART RX -Ereignisse) aufgerufen. Es kann verwendet werden, um eine benutzerdefinierte Kommunikation über Ble UART zu implementieren.
BEMERKUNG!
Diese Funktion ist auf dem RAK11310 nicht erforderlich!
lora_data_handler() wird auf verschiedene Lorawan -Ereignisse aufgerufen
Graph TD
A [Boot] -> | Startup | B (Setup)
B -> | 1 | D (setup_app)
D -> B (Setup)
B -> | 2 | E [Lora und Ble initialisieren]
E -> B (Setup)
B -> | 3 | G (init_app)
G -> k (Setup fertig)
K -> | Startschleife | Ich (Schleife)
Q [Lora Event] -> | Wake Up | J
O [Sensorereignis] -> | Wake Up | JP [Ble Event] -> | Wake Up | Jr [bei Befehl] -> | Wach auf | JT [Timer] -> | Wake Up | Ji -> J (Schlaf)
K -> | Timer starten | T
J -> l (app_event_handler)
J -> M (lora_data_handler)
J -> n (BLE_DATA_HANDLER)
J -> s (bei Befehlshandler)
L -> u (Sensoren lesen)
M -> V (Join, TX- und RX -Ereignisse)
N -> w (Handle BLE bei Befehlen)
S -> AA (Benutzer bei Befehlen)
U -> l
V -> m
W -> n
Aa -> s
L -> J.
M -> J.
N -> j
S -> J.
Alle Befehle finden Sie im Handbuch für ein Kommando , nicht alle RUI3 bei Befehlen werden unterstützt. Eine Liste der verfügbaren bei Befehlen kann abgerufen werden? vom Gerät
Zwei benutzerdefinierte Befehle wurden zum Standard -RUI3 beim Befehlssatz hinzugefügt:
Beschreibung: Stellen Sie das Automatikgetriebeintervall fest
Mit diesem Befehl können das Intervall in Sekunden zwischen automatischen Paketübertragungen festgelegt werden. Wenn Sie auf 0 eingestellt sind, ist die automatische Paketgetriebe deaktiviert.
| Befehl | Eingabeparameter | Rückgabewert | Code zurückgeben |
|---|---|---|---|
| ATC+SENDINT? | - - | ATC+SENDINT: "Get or Set the automatic send interval | OK |
| ATC+SENDINT =? | - - | <interval in seconds> | OK |
ATC+SENDINT = <Input Parameter> | <interval in seconds> | - - | OK oder AT_PARAM_ERROR |
Beispiele :
ATC+SENDINT?
ATC+SENDINT: Get or Set the automatic send interval
OK
ATC+SENDINT=?
ATC+SENDINT:60
OK
ATC+SENDINT=60
OK
Beschreibung: Gerätestatus anzeigen
Mit diesem Befehl kann der Benutzer den aktuellen Gerätestatus erhalten.
| Befehl | Eingabeparameter | Rückgabewert | Code zurückgeben |
|---|---|---|---|
| ATC+Status? | - - | ATC+STATUS: Show LoRaWAN status | OK |
| ATC+Status =? | - - | <Status> | OK |
Beispiele :
ATC+STATUS?
ATC+STATUS: Show LoRaWAN status
OK
// When in LoRaWAN mode:
ATC+STATUS=?
Device status:
RAK4631
Mode LPWAN
Auto join enabled
Network joined
LPWAN status:
Dev EUI AC1F09FFFE09016C
App EUI 70B3D57ED00201E1
App Key 2B84E0B09B68E5CB42176FE753DCEE79
Dev Addr 26021FB4
NWS Key 323D155A000DF335307A16DA0C9DF53F
Apps Key 3F6A66459D5EDCA63CBC4619CD61A11E
OTAA enabled
ADR disabled
Public Network
Dutycycle disabled
Join trials 5
TX Power 0
DR 3
Class 0
Subband 1
Fport 2
Unconfirmed Message
Region AS923-3
Send Frequency 300
// When in LoRa P2P mode:
ATC+STATUS=?
Device status:
RAK4631
Mode P2P
P2P frequency 916000000
P2P TX Power 22
P2P BW 125
P2P SF 7
P2P CR 0
P2P Preamble length 8
P2P Symbol Timeout 0
Send Frequency 300
Beschreibung: Porteinstellungen
Mit diesem Befehl kann der Benutzer die Porteinstellungen zugreifen und konfigurieren.
| Befehl | Eingabeparameter | Rückgabewert | Code zurückgeben |
|---|---|---|---|
| ATC+Port? | - - | AT+PORT=<Port><CR>. Get or Set the Port | OK |
| ATC+Port =? | - - | 1-223 | OK |
ATC+port = <Input Parameter> | 1-223 | - - | OK oder at_param_error |
Beispiele :
ATC+PORT?
ATC+PORT: Get or Set the Port=[1..223]
OK
ATC+PORT=?
ATC+PORT:2
OK
ATC+PORT=2
OK
Zurück
Beginnend mit Wisblock API v1.1.2 können die AT -Befehle durch Benutzer erweitert werden, die bei Befehlen definiert sind. Diese neue Implementierung verwendet die Parser -Funktion der Wisblock -API bei der Befehlsfunktion. Zusätzlich werden benutzerdefinierte bei Befehlen aufgeführt, wenn der AT? wird verwendet.
BEMERKUNG! In RUI3 werden Brandbefehlsbefehl mit ATC anstelle von !
Um die AT -Befehle zu erweitern, sind drei Schritte erforderlich:
Der Brauch bei Befehlen ist in einem Array mit dem Format struct attcmd_t aufgeführt. Jeder Eintrag besteht aus dem AT -Befehl, dem Erläuterungstext, der angezeigt wird, wenn der Befehl mit einem aufgerufen wird? und Zeiger auf die Funktionen für die Abfrage, führen Sie mit Parametern aus und führen Sie ohne Parameter aus. Hier ist ein Beispiel für zwei benutzerdefinierte Befehle:
atcmd_t g_user_at_cmd_list_example[] = {
/* | CMD | AT+CMD? | AT+CMD=? | AT+CMD=value | AT+CMD | Permissions | */
// GNSS commands
{ " +SETVAL " , " Get/Set custom variable " , at_query_value, at_exec_value, NULL , " RW " },
{ " +LIST " , " Show last packet content " , at_query_packet, NULL , NULL , " R " },
};
atcmd_t *g_user_at_cmd_list = g_user_at_cmd_list_example; Bemerkung 1
Die Struktur für Brauch bei Befehlen wird für die Kompatibilität von RUI3 erweitert. Der ältere Code für Wisblock-api v1.x muss an diese neue Struktur angepasst werden.
Bemerkung 2
Für Funktionen, die nicht von dem AT -Befehl unterstützt werden, muss ein NULL in das Array gesteckt werden.
Bemerkung 3
Der Name g_user_at_cmd_list ist behoben und kann nicht geändert werden oder die benutzerdefinierten Befehle werden nicht erkannt.
Bemerkung 4
Die Berechtigungen werden als Zeichenfolge erteilt. Gültige Einträge sind "R" (nur lesen), "W" (nur schreiben), "rw" (lesen und schreiben)
Eine Variable mit der Anzahl der benutzerdefinierten bei Befehlen muss bereitgestellt werden:
/* * Number of user defined AT commands */
uint8_t g_user_at_cmd_num = sizeof (g_user_at_cmd_list_example) / sizeof ( atcmd_t ); BEMERKUNG
Der Name g_user_at_cmd_num ist behoben und kann nicht geändert werden oder die benutzerdefinierten Befehle werden nicht erkannt.
Für jeden benutzerdefinierten Befehl müssen die Anfragen und Ausführungsbefehle geschrieben werden. Die Namen dieser Funktionen müssen mit den Funktionsnamen übereinstimmen, die im Bereich der benutzerdefinierten Befehle verwendet werden. Der Befehl execute empfängt den Wert des AT -Befehls nach = Wert.
Abfragefunktionen ( =? ) Empfangen und Parameter und müssen immer mit 0 zurückkehren. Abfragefunktionen speichern das Ergebnis der Abfrage im globalen Char -Array g_at_query_buffer . Das Array hat eine maximale Größe von ATQUERY_SIZE , die 128 Zeichen beträgt.
Führen Sie Funktionen mit den Parametern aus ( =<value> ). Empfangen Sie Werte oder Einstellungen als Zeiger auf ein Zeichen -Array. Dieses Array enthält nur den Wert oder Parameter ohne den AT -Befehl selbst. Zum Beispiel würde die Ausführungsfunktion ATC+SETDEV=12000 nur den 120000 erhalten. Der empfangene Wert oder Parameter muss auf die Gültigkeit überprüft werden, und wenn der Wert des Formats nicht übereinstimmt, muss ein AT_ERRNO_PARA_VAL zurückgegeben werden. Wenn der Wert oder der Parameter korrekt ist, sollte die Funktion 0 zurückgeben.
Führen Sie Funktionen ohne Parameter aus, um eine Aktion auszuführen und den Erfolg der Aktion als 0 zurückzugeben, wenn erfolgreich oder AT_ERRNO_EXEC_FAIL wenn die Ausführung fehlgeschlagen ist.
Dieses Beispiel wird verwendet, um eine Variable in der Anwendung festzulegen.
/* ******************************************************************* */
// Example AT command to change the value of the variable new_val:
// Query the value AT+SETVAL=?
// Set the value AT+SETVAL=120000
// Second AT command to show last packet content
// Query with AT+LIST=?
/* ******************************************************************* */
int32_t new_val = 3000 ;
/* *
* @brief Returns the current value of the custom variable
*
* @return int always 0
*/
static int at_query_value ()
{
snprintf (g_at_query_buf, ATQUERY_SIZE, " Custom Value: %d " , new_val);
return 0 ;
}
/* *
* @brief Command to set the custom variable
*
* @param str the new value for the variable without the AT part
* @return int 0 if the command was succesfull, 5 if the parameter was wrong
*/
static int at_exec_value ( char *str)
{
new_val = strtol (str, NULL , 0 );
MYLOG ( " APP " , " Value number >>%ld<< " , new_val);
return 0 ;
}
/* *
* @brief Example how to show the last LoRa packet content
*
* @return int always 0
*/
static int at_query_packet ()
{
snprintf (g_at_query_buf, ATQUERY_SIZE, " Packet: %02X%02X%02X%02X " ,
g_lpwan_data. data_flag1 ,
g_lpwan_data. data_flag2 ,
g_lpwan_data. batt_1 ,
g_lpwan_data. batt_2 );
return 0 ;
}
/* *
* @brief List of all available commands with short help and pointer to functions
*
*/
atcmd_t g_user_at_cmd_list_example[] = {
/* | CMD | AT+CMD? | AT+CMD=? | AT+CMD=value | AT+CMD | Permission | */
// GNSS commands
{ " +SETVAL " , " Get/Set custom variable " , at_query_value, at_exec_value, NULL , " RW " },
{ " +LIST " , " Show last packet content " , at_query_packet, NULL , NULL , " R " },
};
atcmd_t *g_user_at_cmd_list = g_user_at_cmd_list_example;
/* * Number of user defined AT commands */
uint8_t g_user_at_cmd_num = sizeof (g_user_at_cmd_list_example) / sizeof ( atcmd_t );Diese fünf Beispiele erklären die Verwendung der API. In allen Beispielen werden die API -Rückrufe und die zusätzlichen Funktionen (Sensorwerte, IRQ -Handling, GNSS -Standortdienst) in ihre eigenen Skizzen unterteilt.
Das Wisblock-API-V2 wurde auch in den folgenden Plattformprojekten verwendet:
Bei der Verwendung mit dem RAK4631 ist das Firmware -Update über BLE bereits in der Bibliothek enthalten. Firmware -Updates für den RAK4631 können mit der nordischen NRF -Toolbox (für Android und iOS verfügbar) oder mit der Wisblock Toolbox (My Android -Anwendung) durchgeführt werden.
Kopieren Sie für das Update die erstellte Aktualisierungsdatei (normalerweise firmware.zip) aus dem Ordner .pio/Build/{Gerät}, kopieren Sie sie an Ihr Telefon und verwenden Sie eine der Anwendungen, um die Firmware zu aktualisieren.
Wenn das Firmware -Update über Ble fehlschlägt, aktualisieren Sie das Gerät mit der Version V0.4.3 auf den neuesten Bootloader für den RAK4631. Sie finden den neuesten Bootloader im Wisblock Repo
Die API bietet einige Anforderungen an die Verwaltung, das Senden von Lorawan -Paket, das Senden von BLE -UART -Daten und das Auslösen von Ereignissen.
void api_set_version(uint16_t sw_1 = 1, uint16_t sw_2 = 0, uint16_t sw_3 = 0);
Diese Funktion kann aufgerufen werden, um die Anwendungsversion festzulegen. Die Anwendungsversion kann bei Befehlen angefordert werden. Die Versionsnummer wird aus drei Ziffern erstellt:
sw_1 ==> Hauptversion erhöht sich bei der Änderung der API / nicht rückwärtskompatibel
sw_2 ==> Minorversion erhöhen bei API -Änderung / rückwärtskompatibel
sw_3 ==> Patch -Version erhöhen auf Bugfix, kein Affekt auf die API
Wenn api_set_version nicht aufgerufen wird, wird die Anwendungsversion auf 1.0.0 standardmäßig.
void api_reset(void);
Führt einen Reset des Wisblock -Kernmoduls durch
void api_wake_loop(uint16_t reason);
Dies wird verwendet, um die Schleife mit einem Ereignis aufzuwecken. Der reason muss in app.h definiert werden. Nach der Loop -Woke -App werden die app_event_handler() mit dem Wert der reason in g_task_event_type aufgerufen.
Dies kann beispielsweise verwendet werden, um das Gerät aus dem Interrupt eines Beschleunigungsmessersensors aufzuwecken. Hier als Beispiel ein Extrakt aus dem accelerometer -Beispielcode.
In accelerometer.ino ist das Ereignis definiert. Der erste Define besteht darin, das Signal einzustellen, das zweite besteht darin, das Ereignis nach dem Umgang mit dem Ereignis zu löschen.
/* * Define additional events */
# define ACC_TRIGGER 0b1000000000000000
# define N_ACC_TRIGGER 0b0111111111111111 Dann in lis3dh_acc.ino in der Interrupt -Callback -Funktion void acc_int_handler(void) Die Schleife wird mit dem Signal ACC_TRIGGER aufgeweckt
void acc_int_handler ( void )
{
// Wake up the task to handle it
api_wake_loop (ACC_TRIGGER);
} Und schließlich in accelerometer.ino Die Veranstaltung wird in app_event_handler() behandelt.
// ACC triggered event
if ((g_task_event_type & ACC_TRIGGER) == ACC_TRIGGER)
{
g_task_event_type &= N_ACC_TRIGGER;
MYLOG ( " APP " , " ACC IRQ wakeup " );
// Reset ACC IRQ register
get_acc_int ();
// Set Status flag, it will trigger sending a packet
g_task_event_type = STATUS;
} void api_log_settings(void);
Diese Funktion kann aufgerufen werden, um die vollständigen Einstellungen des Wisblock -Geräts über USB aufzulisten. Die Ausgabe sieht aus:
Device status:
RAK11310
Auto join enabled
Mode LPWAN
Network joined
Send Frequency 120
LPWAN status:
Dev EUI AC1F09FFFE0142C8
App EUI 70B3D57ED00201E1
App Key 2B84E0B09B68E5CB42176FE753DCEE79
Dev Addr 26021FB4
NWS Key 323D155A000DF335307A16DA0C9DF53F
Apps Key 3F6A66459D5EDCA63CBC4619CD61A11E
OTAA enabled
ADR disabled
Public Network
Dutycycle disabled
Join trials 30
TX Power 0
DR 3
Class 0
Subband 1
Fport 2
Unconfirmed Message
Region AS923-3
LoRa P2P status:
P2P frequency 916000000
P2P TX Power 22
P2P BW 125
P2P SF 7
P2P CR 1
P2P Preamble length 8
P2P Symbol Timeout 0 void api_timer_stop(void)
Stoppt den Timer, der die MCU häufig aufwacht.
void api_timer_restart(uint32_t new_time)
Startet den Timer mit einem neuen Wert neu. Der Wert liegt in Millisekunden
void api_read_credentials(void);
void api_set_credentials(void); Wenn die Lora P2P -Einstellungen hartcodiert sein müssen (z. B. die Frequenz, Bandbreite, ...), kann dies in setup_app() erfolgen. Zunächst müssen die gespeicherten Einstellungen mit api_read_credentials(); und dann können Einstellungen geändert werden. Nach dem Ändern der Einstellungen müssen mit api_set_credentials() gespeichert werden. Da die Wisblock -API überprüft, ob Änderungen gespeichert werden müssen, werden die geänderten Werte erst nach dem Flashen der Anwendung im ersten Start gespeichert.
Beispiel:
// Read credentials from Flash
api_read_credentials ();
// Make changes to the credentials
g_lorawan_settings.p2p_frequency = 916000000 ; // Use 916 MHz to send and receive
g_lorawan_settings.p2p_bandwidth = 0 ; // Bandwidth 125 kHz
g_lorawan_settings.p2p_sf = 7 ; // Spreading Factor 7
g_lorawan_settings.p2p_cr = 1 ; // Coding Rate 4/5
g_lorawan_settings.p2p_preamble_len = 8 ; // Preample Length 8
g_lorawan_settings.p2p_tx_power = 22 ; // TX power 22 dBi
// Save hard coded LoRaWAN settings
api_set_credentials (); Bemerkung 1
Hard codierte Einstellungen müssen in void setup_app(void) eingestellt werden!
Bemerkung 2
Denken Sie daran, dass Parameter, die mit dieser Methode geändert werden, bei Befehl oder BLE verändert werden können , aber nach einem Neustart zurückgesetzt werden !
api_ble_printf() kann verwendet werden, um Daten über die BLE -UART zu senden. print , println und printf werden unterstützt.
BEMERKUNG
Dieser Befehl ist auf dem RAK11310 nicht verfügbar!
Standardmäßig ist die BLE-Werbung nur 30 Sekunden lang nach dem Einschalten/dem Zurücksetzen des Stromverbrauchs aktiv. Durch Aufrufen von void restart_advertising(uint16_t timeout); Die Werbung kann für timeout -Sekunden neu gestartet werden.
BEMERKUNG
Dieser Befehl ist auf dem RAK11310 nicht verfügbar!
lmh_error_status send_lora_packet(uint8_t *data, uint8_t size, uint8_t fport = 0); wird verwendet, um ein Datenpaket an den Lorawan -Server zu senden. *data sind ein Zeiger auf den Puffer, der die Daten enthält. size ist die Größe des Pakets. Wenn der FPORT 0 ist, wird die in der Struktur g_lorawan_setings verwendet.
bool send_p2p_packet(uint8_t *data, uint8_t size); wird verwendet, um ein Datenpaket über Lora P2P zu senden. *data sind ein Zeiger auf den Puffer, der die Daten enthält. size ist die Größe des Pakets.
Nachdem der TX -Zyklus (einschließlich RX1- und RX2 -Fenster) beendet ist, wird das Ergebnis in der globalen Flagge g_rx_fin_result gehalten, das Ereignis LORA_TX_FIN wird ausgelöst und der Rückruf lora_data_handler() wird aufgerufen. In diesem Rückruf kann das Ergebnis überprüft und bei Bedarf Maßnahmen ergriffen werden.
Cayennelpp ist ein Format, das von MyDevices entwickelt wurde, um Lorawan -Knoten in ihre IoT -Plattform zu integrieren.
Die Cayennelpp -Bibliothek erweitert die verfügbaren Datentypen mit mehreren IPSO -Datentypen, die nicht in den ursprünglichen Arbeiten von Johan Stokking oder den meisten Gabeln und Nebenwerken anderer Personen enthalten sind. Diese zusätzlichen Datentypen werden von MyDevices Cayenne nicht unterstützt.
Die Wisblock -API verwendet einige weitere Datentypen, die sowohl die ursprünglichen als auch die elektronischen Datentypen erweitern, um den weiten Bereich der Wisblock -Sensormodule besser zu unterstützen.
Um die erweiterten Datentypen zu verwenden, enthält Wisblock -API bereits die erforderliche Header -Datei.
Um die Cayenne -LPP -Funktionen zu verwenden, ist eine Instanz der Klasse erforderlich.
/* * LoRaWAN packet */
WisCayenne g_solution_data ( 255 );Vor dem Hinzufügen von Daten muss der Paketpuffer zurückgesetzt werden
// Reset the packet
g_solution_data.reset();In der Cayennelpp -Bibliothek werden API -Forderungen für die verschiedenen unterstützten Datentypen gefordert. Einzelheiten finden Sie unter Cayennelpp -API. Zusätzlich zu diesen API -Aufrufen von Wisblock fügt API 5 weitere Anrufe hinzu. Diese API -Aufrufe sind für verschiedene GNSS -Formate und für die VOC -Sensordaten:
uint8_t addGNSS_4 ( uint8_t channel, int32_t latitude, int32_t longitude, int32_t altitude);
uint8_t addGNSS_6 ( uint8_t channel, int32_t latitude, int32_t longitude, int32_t altitude);
uint8_t addGNSS_H ( int32_t latitude, int32_t longitude, int16_t altitude, int16_t accuracy, int16_t battery);
uint8_t addGNSS_T ( int32_t latitude, int32_t longitude, int16_t altitude, float accuracy, int8_t sats);
uint8_t addVoc_index ( uint8_t channel, uint32_t voc_index); /* *
* @brief Add GNSS data in Cayenne LPP standard format
*
* @param channel LPP channel
* @param latitude Latitude as read from the GNSS receiver
* @param longitude Longitude as read from the GNSS receiver
* @param altitude Altitude as read from the GNSS receiver
* @return uint8_t bytes added to the data packet
*/
uint8_t WisCayenne::addGNSS_4 ( uint8_t channel, int32_t latitude, int32_t longitude, int32_t altitude) /* *
* @brief Add GNSS data in custom Cayenne LPP format
* Requires changed decoder in LNS and visualization
* Does not work with Cayenne LPP MyDevices
*
* @param channel LPP channel
* @param latitude Latitude as read from the GNSS receiver
* @param longitude Longitude as read from the GNSS receiver
* @param altitude Altitude as read from the GNSS receiver
* @return uint8_t bytes added to the data packet
*/
uint8_t WisCayenne::addGNSS_6 ( uint8_t channel, int32_t latitude, int32_t longitude, int32_t altitude) /* *
* @brief Add GNSS data in Helium Mapper format
*
* @param channel LPP channel
* @param latitude Latitude as read from the GNSS receiver
* @param longitude Longitude as read from the GNSS receiver
* @param altitude Altitude as read from the GNSS receiver
* @param accuracy Accuracy of reading from the GNSS receiver
* @param battery Device battery voltage in V
* @return uint8_t bytes added to the data packet
*/
uint8_t WisCayenne::addGNSS_H ( int32_t latitude, int32_t longitude, int16_t altitude, int16_t accuracy, int16_t battery) /* *
* @brief Add GNSS data in Field Tester format
*
* @param latitude Latitude as read from the GNSS receiver
* @param longitude Longitude as read from the GNSS receiver
* @param altitude Altitude as read from the GNSS receiver
* @param accuracy Accuracy of reading from the GNSS receiver
* @param sats Number of satellites of reading from the GNSS receiver
* @return uint8_t bytes added to the data packet
*/
uint8_t WisCayenne::addGNSS_T ( int32_t latitude, int32_t longitude, int16_t altitude, float accuracy, int8_t sats) /* *
* @brief Add the VOC index
*
* @param channel VOC channel
* @param voc_index VOC index
* @return uint8_t bytes added to the data packet
*/
uint8_t WisCayenne::addVoc_index ( uint8_t channel, uint32_t voc_index) Die Cayennelpp -Datenpakete befinden sich immer im Format <Channel #><Channel ID><data bytes> .
Damit Datencodierer, die in Lorawan -Servern verwendet werden, und Integrationsdaten, die von Wisblock -Sensoren erfasst wurden, einfacher sind, haben immer die gleiche Kanalnummer (falls diese API verwendet wird). Hier ist die Liste der derzeit zugewiesenen Kanalnummern, Kanal -IDs und welchen Modulen die Kombination verwenden.
| Daten | Kanal # | Kanal -ID | Länge | Kommentar | Erforderliches Modul | Dekodierter Feldname |
|---|---|---|---|---|---|---|
| Batteriewert | 1 | 116 | 2 Bytes | 0,01 V nicht signiertes MSB | RAK4631 | Voltage_1 |
| Luftfeuchtigkeit | 2 | 104 | 1 Byte | in %rel | RAK1901 | Luftfeuchtigkeit_2 |
| Temperatur | 3 | 103 | 2 Bytes | in ° C. | RAK1901 | Temperatur_3 |
| Barometriedruck | 4 | 115 | 2 Bytes | in HPA (Mbar) | RAK1902 | Barometer_4 |
| Beleuchtung | 5 | 101 | 2 Bytes | 1 Lux nicht signiert | RAK1903 | Illuminance_5 |
| Luftfeuchtigkeit 2 | 6 | 104 | 1 Byte | in %rel | RAK1906 | Feuchtigkeit_6 |
| Temperatur 2 | 7 | 103 | 2 Bytes | in ° C. | RAK1906 | Temperatur_7 |
| Barometrischer Druck 2 | 8 | 115 | 2 Bytes | in HPA (Mbar) | RAK1906 | Barometer_8 |
| Gaswiderstand 2 | 9 | 2 | 2 Bytes | 0,01 signiert (Kohm) | RAK1906 | Analog_9 |
| GNSS stehen. Auflösung | 10 | 136 | 9 Bytes | 3 Byte lon/lat 0,0001 °, 3 Bytes Alt 0,01 Meter | RAK1910, RAK12500 | GPS_10 |
| GNSS erhöhte die Auflösung | 10 | 137 | 11 Bytes | 4 Byte lon/lat 0,000001 °, 3 Bytes Alt 0,01 Meter | RAK1910, RAK12500 | GPS_10 |
| Bodentemperatur | 11 | 103 | 2 Bytes | in ° C. | RAK12023/RAK12035 | Temperatur_11 |
| Bodenfeuchtigkeit | 12 | 104 | 1 Byte | in %rel | RAK12023/RAK12035 | Feuchtigkeit_12 |
| Bodenfeuchtigkeit roh | 13 | 2 | 2 Bytes | 0,01 signiert | RAK12023/RAK12035 | analog_in_13 |
| Bodendaten gültig | 14 | 102 | 1 Byte | bool | RAK12023/RAK12035 | Präsenz_14 |
| Beleuchtung 2 | 15 | 101 | 2 Bytes | 1 Lux nicht signiert | RAK12010 | Illuminance_15 |
| VOC | 16 | 138 | 2 Bytes | VOC -Index | RAK12047 | VOC_16 |
| MQ2 -Gas | 17 | 2 | 2 Bytes | 0,01 signiert | RAK12004 | analog_in_17 |
| MQ2 -Gasanteil | 18 | 120 | 1 Byte | 1-100% nicht signiert | RAK12004 | Prozentsatz_18 |
| MG812 Gas | 19 | 2 | 2 Bytes | 0,01 signiert | RAK12008 | analog_in_19 |
| MG812 Gasanteil | 20 | 120 | 1 Byte | 1-100% nicht signiert | RAK12008 | Prozentsatz_20 |
| MQ3 Alkoholgas | 21 | 2 | 2 Bytes | 0,01 signiert | RAK12009 | analog_in_21 |
| MQ3 Alkoholgas Perc. | 22 | 120 | 1 Byte | 1-100% nicht signiert | RAK12009 | Prozentsatz_22 |
| TOF -Abstand | 23 | 2 | 2 Bytes | 0,01 signiert | RAK12014 | analog_in_23 |
| TOF -Daten gültig | 24 | 102 | 1 Byte | bool | RAK12014 | Präsenz_24 |
| Gyro ausgelöst | 25 | 134 | 6 Bytes | 2 Bytes pro Achse, 0,01 °/s | RAK12025 | Gyrometer_25 |
| Geste erkannt | 26 | 0 | 1 Byte | 1 Byte mit Gestenausweis | RAK14008 | digital_in_26 |
| LTR390 UVI -Wert | 27 | 2 | 2 Bytes | 0,01 signiert | RAK12019 | analog_in_27 |
| LTR390 UVS -Wert | 28 | 101 | 2 Bytes | 1 Lux nicht signiert | RAK12019 | Illuminance_28 |
| INA219 Strom | 29 | 2 | 2 Bytes | 0,01 signiert | RAK16000 | Analog_29 |
| INA219 -Spannung | 30 | 2 | 2 Bytes | 0,01 signiert | RAK16000 | Analog_30 |
| Ina219 Power | 31 | 2 | 2 Bytes | 0,01 signiert | RAK16000 | analog_31 |
| Touchpad links | 32 | 102 | 1 Byte | bool | RAK14002 | Präsenz_32 |
| Touchpad Mitte | 33 | 102 | 1 Byte | bool | RAK14002 | Präsenz_33 |
| Touchpad richtig | 34 | 102 | 1 Byte | bool | RAK14002 | Präsenz_34 |
| SCD30 CO2 -Konzentration | 35 | 125 | 2 Bytes | 1 ppm nicht signiert | RAK12037 | Konzentration_35 |
| SCD30 Temperatur | 36 | 103 | 2 Bytes | in ° C. | RAK12037 | Temperatur_36 |
| SCD30 Feuchtigkeit | 37 | 104 | 1 Byte | in %rel | RAK12037 | Feuchtigkeit_37 |
| MLX90632 Sensortemperatur | 38 | 103 | 2 Bytes | in ° C. | RAK12003 | Temperatur_38 |
| MLX90632 Objekttemp | 39 | 103 | 2 Bytes | in ° C. | RAK12003 | Temperatur_39 |
| PM 1.0 Wert | 40 | 103 | 2 Bytes | in ug/m3 | RAK12003 | VOC_40 |
| PM 2.5 Wert | 41 | 103 | 2 Bytes | in ug/m3 | RAK12003 | VOC_41 |
| PM 10 Wert | 42 | 103 | 2 Bytes | in ug/m3 | RAK12003 | VOC_42 |
| Erdbebenereignis | 43 | 102 | 1 Byte | bool | RAK12027 | Präsenz_43 |
| Erdbeben -SI -Wert | 44 | 2 | 2 Bytes | Analog 10 * m/s | RAK12027 | analog_44 |
| Erdbeben -PGA -Wert | 45 | 2 | 2 Bytes | Analog 10 * m/s2 | RAK12027 | analog_45 |
| Erdbeben -Absperrung | 46 | 102 | 1 Byte | bool | RAK12027 | Präsenz_46 |
| Lpp_channel_eq_collapse | 47 | 102 | 1 Byte | bool | RAK12027 | Präsenz_47 |
| Status umschalten | 48 | 102 | 1 Byte | bool | RAK13011 | Präsenz_48 |
Kanal -IDs in Kurven werden erweitert und werden nicht von Standard -Decodern von Standard -LPP -Daten von Cayenne -LPP unterstützt.
Eine vollständige und aktualisierte Liste gebrauchter Datenformate finden Sie in unserem rakwireless_Standardized_payload
Das Repo von RakWireless_Standardized_Payload enthält auch einen passenden Decoder.
Der hier verwendete Code ist das Beispiel für api-test.ino.
Dies sind die erforderlichen Einflüsse und Definitionen für die Benutzeranwendung und die API -Schnittstelle
In diesem Beispiel haben wir die Lorawan-Anmeldeinformationen hart codiert. Es wird dringend empfohlen , dies nicht zu tun, um doppelte Knotenanmeldeinformationen zu vermeiden
Alternative Optionen zum Einrichten von Anmeldeinformationen sind
# include < Arduino.h >
/* * Add you required includes after Arduino.h */
# include < Wire.h >
// Debug output set to 0 to disable app debug output
# ifndef MY_DEBUG
# define MY_DEBUG 1
# endif
# ifdef NRF52_SERIES
# if MY_DEBUG > 0
# define MYLOG (tag, ...)
do
{
if (tag)
PRINTF ( " [%s] " , tag);
PRINTF (__VA_ARGS__);
PRINTF ( " n " );
if (g_ble_uart_is_connected)
{
g_ble_uart. printf (__VA_ARGS__);
g_ble_uart. printf ( " n " );
}
} while ( 0 )
# else
# define MYLOG (...)
# endif
# endif
# ifdef ARDUINO_ARCH_RP2040
# if MY_DEBUG > 0
# define MYLOG (tag, ...)
do
{
if (tag)
Serial. printf ( " [%s] " , tag);
Serial. printf (__VA_ARGS__);
Serial. printf ( " n " );
} while ( 0 )
# else
# define MYLOG (...)
# endif
# endif
/* * Include the WisBlock-API-V2 */
# include < WisBlock-API-V2.h > // Click to install library: http://librarymanager/All#WisBlock-API-V2
/* * Define the version of your SW */
# define SW_VERSION_1 1 // major version increase on API change / not backwards compatible
# define SW_VERSION_2 0 // minor version increase on API change / backward compatible
# define SW_VERSION_3 0 // patch version increase on bugfix, no affect on API
/* *
Optional hard-coded LoRaWAN credentials for OTAA and ABP.
It is strongly recommended to avoid duplicated node credentials
Options to setup credentials are
- over USB with AT commands
- over BLE with My nRF52 Toolbox
*/
uint8_t node_device_eui[ 8 ] = { 0x00 , 0x0D , 0x75 , 0xE6 , 0x56 , 0x4D , 0xC1 , 0xF3 };
uint8_t node_app_eui[ 8 ] = { 0x70 , 0xB3 , 0xD5 , 0x7E , 0xD0 , 0x02 , 0x01 , 0xE1 };
uint8_t node_app_key[ 16 ] = { 0x2B , 0x84 , 0xE0 , 0xB0 , 0x9B , 0x68 , 0xE5 , 0xCB , 0x42 , 0x17 , 0x6F , 0xE7 , 0x53 , 0xDC , 0xEE , 0x79 };
uint8_t node_nws_key[ 16 ] = { 0x32 , 0x3D , 0x15 , 0x5A , 0x00 , 0x0D , 0xF3 , 0x35 , 0x30 , 0x7A , 0x16 , 0xDA , 0x0C , 0x9D , 0xF5 , 0x3F };
uint8_t node_apps_key[ 16 ] = { 0x3F , 0x6A , 0x66 , 0x45 , 0x9D , 0x5E , 0xDC , 0xA6 , 0x3C , 0xBC , 0x46 , 0x19 , 0xCD , 0x61 , 0xA1 , 0x1E };Weitere Funktionen einiger Funktionen (bei der Verwendung von Platformio erforderlich)
/* * Application function definitions */
void setup_app ( void );
bool init_app ( void );
void app_event_handler ( void );
void ble_data_handler ( void ) __attribute__((weak));
void lora_data_handler ( void );Hier ist der Anwendungsname auf Rak-Test gesetzt. Der Name wird mit der NRF52 eindeutigen Chip -ID erweitert. Dieser Name wird in der BLE -Werbung verwendet.
/* * Application stuff */
/* * Set the device name, max length is 10 characters */
char g_ble_dev_name[ 10 ] = " RAK-TEST " ;Einige Flaggen und Signale sind erforderlich
/* * Flag showing if TX cycle is ongoing */
bool lora_busy = false ;
/* * Send Fail counter * */
uint8_t send_fail = 0 ; Diese Funktion wird zu Beginn des Anwendungsstarts aufgerufen. In dieser Funktion sollte alles eingerichtet werden, das vor dem Ausführen von Arduino setup() erforderlich ist. Dies könnte zum Beispiel die Lorawan -Anmeldeinformationen sein. In diesem Beispiel haben wir die Lorawan-Anmeldeinformationen hart codiert. Es wird dringend empfohlen , dies nicht zu tun, um doppelte Knotenanmeldeinformationen zu vermeiden
Alternative Optionen zum Einrichten von Anmeldeinformationen sind
g_enable_ble festgelegt. Wenn wahr, wird die BLE -Schnittstelle initialisiert. Wenn falsch, wird die BLE -Schnittstelle nicht aktiviert, was den Stromverbrauch senken kann. void setup_app ( void )
{
Serial. begin ( 115200 );
time_t serial_timeout = millis ();
// On nRF52840 the USB serial is not available immediately
while (!Serial)
{
if (( millis () - serial_timeout) < 5000 )
{
delay ( 100 );
digitalWrite (LED_GREEN, ! digitalRead (LED_GREEN));
}
else
{
break ;
}
}
digitalWrite (LED_GREEN, LOW);
MYLOG ( " APP " , " Setup WisBlock API Example " );
# ifdef NRF52_SERIES
// Enable BLE
g_enable_ble = true ;
# endif
// Set firmware version
api_set_version (SW_VERSION_1, SW_VERSION_2, SW_VERSION_3);
// Optional
// Setup LoRaWAN credentials hard coded
// It is strongly recommended to avoid duplicated node credentials
// Options to setup credentials are
// -over USB with AT commands
// -over BLE with My nRF52 Toolbox
// Read LoRaWAN settings from flash
api_read_credentials ();
// Change LoRaWAN settings
g_lorawan_settings. auto_join = true ; // Flag if node joins automatically after reboot
g_lorawan_settings. otaa_enabled = true ; // Flag for OTAA or ABP
memcpy (g_lorawan_settings. node_device_eui , node_device_eui, 8 ); // OTAA Device EUI MSB
memcpy (g_lorawan_settings. node_app_eui , node_app_eui, 8 ); // OTAA Application EUI MSB
memcpy (g_lorawan_settings. node_app_key , node_app_key, 16 ); // OTAA Application Key MSB
memcpy (g_lorawan_settings. node_nws_key , node_nws_key, 16 ); // ABP Network Session Key MSB
memcpy (g_lorawan_settings. node_apps_key , node_apps_key, 16 ); // ABP Application Session key MSB
g_lorawan_settings. node_dev_addr = 0x26021FB4 ; // ABP Device Address MSB
g_lorawan_settings. send_repeat_time = 120000 ; // Send repeat time in milliseconds: 2 * 60 * 1000 => 2 minutes
g_lorawan_settings. adr_enabled = false ; // Flag for ADR on or off
g_lorawan_settings. public_network = true ; // Flag for public or private network
g_lorawan_settings. duty_cycle_enabled = false ; // Flag to enable duty cycle (validity depends on Region)
g_lorawan_settings. join_trials = 5 ; // Number of join retries
g_lorawan_settings. tx_power = 0 ; // TX power 0 .. 15 (validity depends on Region)
g_lorawan_settings. data_rate = 3 ; // Data rate 0 .. 15 (validity depends on Region)
g_lorawan_settings. lora_class = 0 ; // LoRaWAN class 0: A, 2: C, 1: B is not supported
g_lorawan_settings. subband_channels = 1 ; // Subband channel selection 1 .. 9
g_lorawan_settings. app_port = 2 ; // Data port to send data
g_lorawan_settings. confirmed_msg_enabled = LMH_UNCONFIRMED_MSG; // Flag to enable confirmed messages
g_lorawan_settings. resetRequest = true ; // Command from BLE to reset device
g_lorawan_settings. lora_region = LORAMAC_REGION_AS923_3; // LoRa region
// Save LoRaWAN settings
api_set_credentials ();Diese Funktion wird nach BLE und LORA bereits initialisiert. Im Idealfall ist dies der Ort, um anwendungsspezifische Dinge wie Sensoren oder Aktuatoren zu initialisieren. In diesem Beispiel ist es ungenutzt
/* *
* @brief Application specific initializations
*
* @return true Initialization success
* @return false Initialization failure
*/
bool init_app ( void )
{
MYLOG ( " APP " , " init_app " );
return true ;
} Dieser Rückruf wird zum Statusereignis aufgerufen. Das Statusereignis wird häufig ausgelöst, die Zeit wird durch send_repeat_time festgelegt. Es wird auch von benutzerdefinierten Ereignissen ausgelöst. Siehe Beispiel RAK1904_Example _ Wie benutzerdefinierte Ereignisse definiert werden. _ Es ist wichtig, dass Ereignisflaggen zurückgesetzt werden. Als Beispiel wird das Statusereignis durch diese Codesequenz zurückgesetzt:
if ((g_task_event_type & STATUS) == STATUS)
{
g_task_event_type &= N_STATUS;
...
} Mit dem Statusereignis wird häufig Uplink -Pakete an den Lorawan -Server gesendet.
In diesem Beispielcode starten wir auch die BLE -Werbung für 15 Sekunden. Andernfalls ist Ble Adverstising nach dem Einschalten/dem Zurücksetzen nur 30 Sekunden lang aktiv.
void app_event_handler ( void )
{
// Timer triggered event
if ((g_task_event_type & STATUS) == STATUS)
{
g_task_event_type &= N_STATUS;
MYLOG ( " APP " , " Timer wakeup " );
# ifdef NRF52_SERIES
// If BLE is enabled, restart Advertising
if (g_enable_ble)
{
restart_advertising ( 15 );
}
# endif
if (lora_busy)
{
MYLOG ( " APP " , " LoRaWAN TX cycle not finished, skip this event " );
}
else
{
// Dummy packet
uint8_t dummy_packet[] = { 0x10 , 0x00 , 0x00 };
lmh_error_status result = send_lora_packet (dummy_packet, 3 );
switch (result)
{
case LMH_SUCCESS:
MYLOG ( " APP " , " Packet enqueued " );
// Set a flag that TX cycle is running
lora_busy = true ;
break ;
case LMH_BUSY:
MYLOG ( " APP " , " LoRa transceiver is busy " );
break ;
case LMH_ERROR:
MYLOG ( " APP " , " Packet error, too big to send with current DR " );
break ;
}
}
}
} Dieser Rückruf wird verwendet, um Daten zu verarbeiten, die über die BLE -UART empfangen werden. Wenn Sie keine ble UART -Funktionalität benötigen, können Sie diese Funktion vollständig entfernen. In diesem Beispiel leiten wir die empfangenen UART -Daten an den AT -Befehlsinterpreter weiter. Auf diese Weise können wir bei Befehlen entweder über den USB -Anschluss oder über den BLE -UART -Anschluss einreichen.
Die BLE -Kommunikation wird nur am RAK4631 unterstützt. Der RAK11310 hat keine BLE.
# ifdef NRF52_SERIES
void ble_data_handler ( void )
{
if (g_enable_ble)
{
/* ************************************************************ */
/* ************************************************************ */
// / todo BLE UART data arrived
// / todo or forward them to the AT command interpreter
// / todo parse them here
/* ************************************************************ */
/* ************************************************************ */
if ((g_task_event_type & BLE_DATA) == BLE_DATA)
{
MYLOG ( " AT " , " RECEIVED BLE " );
// BLE UART data arrived
// in this example we forward it to the AT command interpreter
g_task_event_type &= N_BLE_DATA;
while (g_ble_uart. available () > 0 )
{
at_serial_input ( uint8_t (g_ble_uart. read ()));
delay ( 5 );
}
at_serial_input ( uint8_t ( ' n ' ));
}
}
}
# endif Dieser Rückruf wird auf drei verschiedene Ereignisse aufgerufen:
Das Ereignis lora_data wird ausgelöst, wenn ein Downlink -Paket vom Lorawan -Server oder ein Lora P2P -Paket eingetroffen ist. In diesem Beispiel analysieren wir die Daten nicht, sie werden nur auf das Protokoll und über die BLE -UART ausgedruckt (wenn ein Gerät angeschlossen ist)
Das Ereignis lora_tx_fin wird ausgelöst, nachdem das Senden eines Uplink -Pakets fertiggestellt ist, einschließlich der RX1- und RX2 -Fenster. Wenn bestätigte Pakete gesendet werden, enthält das globale Flag g_rx_fin_result das Ergebnis der bestätigten Übertragung. Wenn g_rx_fin_result wahr ist, bestätigte der Lorawan -Server das Uplink -Paket durch Senden eines ACK . Andernfalls ist das g_rx_fin_result auf false eingestellt, was angibt, dass das Paket nicht vom Lorawan -Server empfangen wurde (kein Gateway in Reichweite, das Paket wurde in der Luft beschädigt. Wenn nicht bestätigte Pakete gesendet werden oder wenn der Lora -P2P -Modus verwendet wird, wird der Flag g_rx_fin_result immer wahr.
Das Ereignis lora_join_fin wird aufgerufen, nachdem die Anfrage/Join -Akzeptanz/Ablehnung abgeschlossen ist. Das globale Flagg g_task_event_type enthält das Ergebnis der Join -Anforderung. Wenn der Knoten wahr ist, hat sich der Knoten dem Netzwerk angeschlossen. Wenn falsch ist der Join nicht erfolgreich. In diesem Fall könnte der Join -Zyklus neu gestartet werden oder der Knoten könnte einen Fehler melden.
void lora_data_handler ( void )
{
// LoRa data handling
if ((g_task_event_type & LORA_DATA) == LORA_DATA)
{
/* ************************************************************ */
/* ************************************************************ */
// / todo LoRa data arrived
// / todo parse them here
/* ************************************************************ */
/* ************************************************************ */
g_task_event_type &= N_LORA_DATA;
MYLOG ( " APP " , " Received package over LoRa " );
char log_buff[g_rx_data_len * 3 ] = { 0 };
uint8_t log_idx = 0 ;
for ( int idx = 0 ; idx < g_rx_data_len; idx++)
{
sprintf (&log_buff[log_idx], " %02X " , g_rx_lora_data[idx]);
log_idx += 3 ;
}
lora_busy = false ;
MYLOG ( " APP " , " %s " , log_buff);
}
// LoRa TX finished handling
if ((g_task_event_type & LORA_TX_FIN) == LORA_TX_FIN)
{
g_task_event_type &= N_LORA_TX_FIN;
MYLOG ( " APP " , " LPWAN TX cycle %s " , g_rx_fin_result ? " finished ACK " : " failed NAK " );
if (!g_rx_fin_result)
{
// Increase fail send counter
send_fail++;
if (send_fail == 10 )
{
// Too many failed sendings, reset node and try to rejoin
delay ( 100 );
sd_nvic_SystemReset ();
}
}
// Clear the LoRa TX flag
lora_busy = false ;
}
// LoRa Join finished handling
if ((g_task_event_type & LORA_JOIN_FIN) == LORA_JOIN_FIN)
{
g_task_event_type &= N_LORA_JOIN_FIN;
if (g_join_result)
{
MYLOG ( " APP " , " Successfully joined network " );
}
else
{
MYLOG ( " APP " , " Join network failed " );
// / todo here join could be restarted.
// lmh_join();
}
}
} In Arduino ist es nicht möglich, Einstellungen in der .ino -Datei zu definieren, die das Verhalten der enthaltenen Bibliotheken steuern können. Um das Debug-Protokoll und die Verwendung der blauen LED zu ändern, müssen Sie die Datei WisBlock-API-V2.h im Quellordner der Bibliotheken öffnen.
So aktivieren/deaktivieren Sie das API-Debug ( API_LOG() ) die Datei WisBlock-API-V2.h im Quellordner der Bibliotheken.
Suchen
# define API_DEBUG 1in der Datei.
0 -> No debug output
1 -> API debug output
Um das Anwendungsdebug ( MY_LOG() ) zu aktivieren/zu deaktivieren, finden Sie in den Beispielen (entweder in der .ino -Datei oder in der App.h)
# define MY_DEBUG 1in der Datei.
0 -> No debug output
1 -> Application debug output
Suchen
# define NO_BLE_LED 1 In der Datei WisBlock-API-V2
0 -> the blue LED will be used to indicate BLE status
1 -> the blue LED will not used
BEMERKUNG
RAK11310 hat kein Ble und die blaue LED kann für andere Zwecke verwendet werden.
Die Debug -Ausgabe kann durch Definition im Platformio.ini API_DEBUG Debug -Ausgabe der Wisblock -API gesteuert werden
0 -> No debug outpuy
1 -> WisBlock API debug output
MY_DEBUG steuert Debug -Ausgabe der Anwendung selbst
0 -> No debug outpuy
1 -> Application debug output
NO_BLE_LED steuert die Verwendung der blauen LED.
0 -> the blue LED will be used to indicate BLE status
1 -> the blue LED will not used
Beispiel für keine Debug -Ausgabe und keine blaue LED
build_flags =
- DAPI_DEBUG =0 ; 0 Disable WisBlock API debug output
- DMY_DEBUG =0 ; 0 Disable application debug output
- DNO_BLE_LED =1 ; 1 Disable blue LED as BLE notificatorBibliothek unter MIT -Lizenz veröffentlicht
Credits:
Bei Befehlsfunktionen: Taylor Lee ([email protected])
Code -Veröffentlichungen
api_read_credentials()api_set_credentials() speichert auf FlashWisBlock API LoRaWAN anstelle von GNSS
