[Lawrence Griffiths]

@jason thanks

[Lawrence Griffiths]

@Jason apologies got my RP versions wrong (v1.0.2 rev B & v1.0.2 Final)

Thanks for the heads up.

To confirm if mac 1.0.3 and RP 1.0.3 the AEP are set, the LNS will include the CFList in JoinAccept for US902-928 region?

[Lawrence Griffiths]

Jason will do
Thanks

[Lawrence Griffiths]

Jason thanks, have done that looking good.

Lawrence

• This reply was modified 6 years ago by Lawrence Griffiths.

[Lawrence Griffiths]

Jeff thanks I’m try this in the office as I’ve arranged to swap the GW out.

Lawrence

[Lawrence Griffiths]

Ok so I should be ok in the field as once I’ve dropped DR & device is using it I send a ADR disable cmd which it has.

But doesn’t look like my edge case will be solvable with manual ADR when running on v1.7.0.

Thanks
Lawrence

[Lawrence Griffiths]

Jason thanks helps to look..

I’m running AEP v1.7.0 on a Conduit
I have a v1.6.2 in the field and in the office should I try that?

Lawrence

[Lawrence Griffiths]

Jaco depends on the region I belive
Normally 20 uplink msg and the network server will adjust
Also the end-device can adjust too
https://www.sghoslya.com/p/how-does-lorawan-nodes-changes-their.html

[Lawrence Griffiths]

Bob do your servers send a response code to updates from Node-Red?
If you do then you could try & count the number of missed and use exe node to a Linux reboot. As it might be more of an connection issues.

Also on latest version of AEP the node-red logs are not rotated I would have a look at those.

• This reply was modified 6 years, 2 months ago by Lawrence Griffiths.

[Lawrence Griffiths]

William thanks my bad hadn’t checked the Post header Content-Type !!
I wanted to write to the tags field/key Failed! So deiced to test write to other fields. results below

class STRING fail // failed to update device
firmware_version STRING pass
hardware_version INT pass
product_id STRING pass
serial_number STRING pass
tags STRING fail
name STRING fail

Lawrence

[Lawrence Griffiths]

Jason thanks

Been trying diffident keys/deveui formats etc all of the below result in
“Invalid json device configuration, object expected”
All the JSON I’m submitting is valid

{“deveui”:”a81758fffe03757f”, “serial_number” : “1234”}
{“deveui”:”a8-17-58-ff-fe-03-75-7f”, “serial_number” : “1234”}

{“dev_eui”:”a81758fffe03757f”, “serial_number” : “1234”}
{“dev_eui”:”a8-17-58-ff-fe-03-75-7f”, “serial_number” : “1234”}

{“a8-17-58-ff-fe-03-75-7f”: {“serial_number” : “1234”}}
{“a81758fffe03757f”: {“serial_number” : “1234”}}

Not sure what to try next?
This is something I was doing to show Campbell Elder…

[Lawrence Griffiths]

Jason, thanks for that.
I was going to get a nodejs Dev to look at lora-in node.

Any chance of taking this up with the Dev team?
Other wise we will look to fork and fix lora-in.

Lawrence

[Lawrence Griffiths]

We’ve been seeing this problem on and off for a year.
As the number of our AEP Gateways increases it’s becoming more of an issue.

Given the low number of AEP sales I don’t think it’s a priority for MT to look at without log based evidence.

My hunch is the problem with the LoRa-in node.
Adding a [mqtt in] node to [local host] and sub to topic lora\+\up we can sometimes see uplink messages, but no LoRa-in messages.

A re-deploy of node-red flow often sorts the the problem.
We are testing a dead-mans handle which re-starts node-red via AEP API
POST to http://127.0.0.1/api/command/restart_node_red does it though it will take about 4 mins to re-start.

Lawrence

[Lawrence Griffiths]

// This should do the tick
// In function node

var downlinkMsg = new Buffer(‘04000105′,’hex’);
var msg = {
“payload”: downlinkMsg,
“eui”: “00:11:22:33:44:55:66:88”,
“ack”: false,
“port”: 1
};

return msg;

[Lawrence Griffiths]

Jason thanks as always for prompt responce

[Lawrence Griffiths]

Jason thanks for those wanting to know what version on mLinux their AEP is running this worked
cat /etc/issue

MultiTech Systems Application Execution Platform with mLinux GNU/Linux

mLinux 3.3.6 \n \l

[Lawrence Griffiths]

Jason thanks can I use the new MTAC-LORA-H SPI on an older conduit? Or do you have a specific new version?

[Lawrence Griffiths]

Jason it looks like parseInt(port_config, 10); fixed that issue in lora.js`

node.on('input', function(msg) {
var eui = msg.eui || config.eui;
var payload = msg.payload || config.payload;
var ack_config = msg.ack || config.ack;
var port_config = msg.port || config.port;
port_config = parseInt(port_config, 10);


But there is another bug you can’t override the node port setting from msg.port also if you set the node config port drop down to blank you get null in port no

{"data":"A0AHAAE=","ack":false,"port":null}

Could you pls raise ticket for both of these thanks.
Lawrence

• This reply was modified 7 years, 9 months ago by Lawrence Griffiths.
• This reply was modified 7 years, 9 months ago by Lawrence Griffiths.

[Lawrence Griffiths]

Let me test the change first I do tomorrow as it’s 10pm hear in UK.. thta’s me for the night

[Lawrence Griffiths]

That worked
msg.topic = “lora/devEUI/down”;
msg.payload = ‘{“data”:”A0AHAAE=”,”port”:0}’;

Think the issue in lora-out node not doing type testing on port no.
Will mod and test think there should be something like port_config = parseInt(port_config, 10);

Thanks for your help Jason

[Lawrence Griffiths]

Jason you can’t overwrite the lora-out node port setting from input msg. You can only set it from the node options. I take a look at the nodejs and see what that yields. But feel like we are in Bug territory .

Do think this NR/out as it passed the downlink msg a JSON to MQTT which assume feeds the lora network server.

lora/0e:7e:34:64:33:30:67:44/down : [msg.payload] : string
{“data”:”A0AHAAE=”,”ack”:false,”port”:”0″}


var msg = { data: new Buffer(payload).toString("base64"), ack: ack_config, port: port_config };
client.publish('lora/' + eui + '/down', JSON.stringify(msg));


• This reply was modified 7 years, 9 months ago by Lawrence Griffiths.

[Lawrence Griffiths]

Jason have tried and not got the outcome I hoped for
Looks like the PORT is set to 1 from last block

17:6:25:715|DEBUG|ED:0e-7e-34-64-33-30-67-44|PACKET-TX|ADDR: 00000001 PORT: 1 ACK: 0 FCNT: 00000005

// MAC TX followed by Node-RED mac

16:58:58:443|DEBUG|GW:00:80:00:00:00:00:9a:26|FRAME-TX|DATA: 600100000005010003520700017bce238a
17:6:25:716|DEBUG|GW:00:80:00:00:00:00:9a:26|FRAME-TX|DATA: 6001000000000500018a8e0a31f16a39f031

var macBuf = new Buffer(‘0340070001′,’hex’);
var msg = {
“payload”: macBuf,
“eui”: “0e:7e:34:64:33:30:67:44”,
“ack”: false,
“port”: 0
};
`
// ADR from network server – works

 
16:58:57:709|INFO|ED:0e-7e-34-64-33-30-67-44|SCHED-TX|Use RX1 TOA:56 ms
16:58:57:715|DEBUG|GW:00:80:00:00:00:00:9a:26|FRAME-RX|JSON: {"chan":0,"codr":"4/5","data":"QAEAAACCCAADBxQpdEA7z/Ew","datr":"SF7BW125","freq":868.10000000000002,"lsnr":9.8000000000000007,"modu":"LORA","rfch":0,"rssi":-33,"size":18,"stat":1,"time":"2017-07-05T16:58:57.678346Z","tmst":3861837027}
16:58:58:439|INFO|GW:00:80:00:00:00:00:9a:26|FRAME-TX|IP: 127.0.0.1:47267 CH: LC1 NODE: 00:00:00:01 FCNT: 00000002 REPEAT: 0
16:58:58:443|INFO|ED:0e-7e-34-64-33-30-67-44|MAC-COMMAND|ADR CMD 0352070001
16:58:58:443|INFO|ED:0e-7e-34-64-33-30-67-44|SCHED-TX|Q-SIZE: 0 PKT-SIZE: 528 PKT-ROOM: 237
16:58:58:443|DEBUG|GW:00:80:00:00:00:00:9a:26|FRAME-TX|DATA: 600100000005010003520700017bce238a
16:58:58:444|DEBUG|GW:00:80:00:00:00:00:9a:26|PACKET-TX|RX1 OFFSET: 1000000
16:58:58:477|DEBUG|GW:00:80:00:00:00:00:9a:26|FRAME-TX|JSON: {"txpk":{"appeui":"00-00-01-00-00-aa-aa-aa","codr":"4/5","data":"YAEAAAAFAQADUgcAAXvOI4o","datr":"SF7BW125","deveui":"0e-7e-34-64-33-30-67-44","freq":868.10000000000002,"ipol":true,"modu":"LORA","ncrc":true,"powe":11,"rfch":0,"size":17,"tmst":3862837027}}
16:58:58:484|DEBUG|GW:00:80:00:00:00:00:9a:26|DUTY-CYCLE|BAND: 1 DUTY: 34883
16:58:58:484|INFO|Update DC Band: 1 Duration: 51 time-on-air available: 34832 ms

Failed form Node-RED

lora/0e:7e:34:64:33:30:67:44/down : [msg.payload] : string
{"data":"A0AHAAE=","ack":false,"port":"0"}

17:6:25:671|INFO|GW:00:80:00:00:00:00:9a:26|FRAME-TX|IP: 127.0.0.1:47267 CH: LC1 NODE: 00:00:00:01 FCNT: 00000006 REPEAT: 0
17:6:25:715|INFO|ED:0e-7e-34-64-33-30-67-44|SCHED-TX|Q-SIZE: 1 PKT-SIZE: 5 PKT-ROOM: 242
17:6:25:715|DEBUG|ED:0e-7e-34-64-33-30-67-44|PACKET-TX|ADDR: 00000001 PORT: 1 ACK: 0 FCNT: 00000005
17:6:25:716|DEBUG|GW:00:80:00:00:00:00:9a:26|FRAME-TX|DATA: 6001000000000500018a8e0a31f16a39f031
17:6:25:716|DEBUG|GW:00:80:00:00:00:00:9a:26|PACKET-TX|RX1 OFFSET: 1000000
17:6:25:718|DEBUG|GW:00:80:00:00:00:00:9a:26|FRAME-TX|JSON: {"txpk":{"appeui":"00-00-01-00-00-aa-aa-aa","codr":"4/5","data":"YAEAAAAABQABio4KMfFqOfAx","datr":"SF7BW125","deveui":"0e-7e-34-64-33-30-67-44","freq":868.10000000000002,"ipol":true,"modu":"LORA","ncrc":true,"powe":11,"rfch":0,"size":18,"tmst":15101763}}
17:6:25:719|DEBUG|GW:00:80:00:00:00:00:9a:26|DUTY-CYCLE|BAND: 1 DUTY: 36000
17:6:25:722|INFO|Update DC Band: 1 Duration: 51 time-on-air available: 35949 ms

• This reply was modified 7 years, 9 months ago by Lawrence Griffiths.
• This reply was modified 7 years, 9 months ago by Lawrence Griffiths.
• This reply was modified 7 years, 9 months ago by Lawrence Griffiths.
• This reply was modified 7 years, 9 months ago by Lawrence Griffiths.
• This reply was modified 7 years, 9 months ago by Lawrence Griffiths.
• This reply was modified 7 years, 9 months ago by Lawrence Griffiths.

[Lawrence Griffiths]

Ajay, when we think we are having collisions ADR has both end-nodes on same SF so my understanding is (with in power limits) two end-nodes on TX on same channel same time if the both have dif SF they will both be processed.

Also we have a situation where RF environment changes and has caused well performing nodes to fall off net occasionally coming back online. ADR needs to at least 20 packets to access a change in DR. So when we see a nodes who RSSI has a big delta we want to take action then.

[Lawrence Griffiths]

Jason thanks is it as simple as sending the following from a function node to lora-out node

var msg = {
“payload”: 0x50ff0001,
“eui”: “00:11:22:33:44:55:66:88”,
“ack”: true,
“port”: 0
};

// MAC LinkADRReq cmd
// 50ff0001
03 LinkADRReq Mac cmd 03
5 DataRate ms nibble of DataRate_TXPower
0 TXPower ls nibble of DataRate_TXPower
ff00 ChMask
01 Redundancy

I copied 50ff0001 from AEP logs and used to understand the mac command. One thing that I noticed if my understanding is correct the TX power setting is 0 which in EU section of LoRaWAN Regional Parameters 20 dBm I thought 14 dBm was mx power for EU?

[Lawrence Griffiths]

Jason, accepting the security risk on uplink counter validation. Could disabling strict work for when AEP is power cycled and end-node keeps transmitting. As assume Netserver counters are lost and end-node keeps tx-ing so counters are out of sync and can’t be validated?

Reason for asking I have live project where end-node supplier Doesn’t check to see if they are still joined to network. I can’t go and power cycle 200+ sensors which are in different country. So pondering what I can do?

Lawrence

• This reply was modified 7 years, 9 months ago by Lawrence Griffiths.

[Lawrence Griffiths]

Eric I’ve been waiting for nodejs BACnet for years!
This is still VERY beta.

One way I’m working for building automation (KNX & EnOcean) integration to LoRaWAN is to use a Raspberry PI running Node-RED along side the AEP then use web sockets to talk between both.

• This reply was modified 7 years, 9 months ago by Lawrence Griffiths.

[Lawrence Griffiths]

Jason, thanks & agreed … Appears to be more of a nuisance for most.

[Lawrence Griffiths]

Work-arounds:
1. UPS + GPIO card to gracefully shutdown gateway before UPS battery runs out.

Assume this standard linux shutdown cmd? or is something else.

Thanks
Lawrence

[Lawrence Griffiths]

Thanks for the update

[Lawrence Griffiths]

Ajay thanks for this

[Author]

Posts