Sending data to Azure
Home › Forums › Conduit: AEP Model › Sending data to Azure
- This topic has 8 replies, 3 voices, and was last updated 8 years, 9 months ago by Terrence Spencer.
-
AuthorPosts
-
February 16, 2016 at 9:24 pm #11683Terrence SpencerParticipant
I want to configure my [MTCDT-210A Firmware1.1.2] to receive messages and then send them off to my Azure api webservice.
Could someone give me a brief outline of how to configure my conduit to do this?
I have read quite a bit, but am still in need of a grounding understanding of how to do this.
February 17, 2016 at 7:52 am #11684Jeff HatchKeymasterTerrence,
By “configure my [MTCDT-210A Firmware1.1.2] to receive messages” do you mean that you are using LoRa to receive the messages and want to use Node-RED to send these messages to your Azure API webservice? In that case, on the Node-RED end of things you can start with the following link:
There is a link that talks about configuring LoRa here:
Getting Started with LoRa Conduit mLinux (LoRa Configuration)
Hope that helps,
Jeff
February 17, 2016 at 8:53 am #11685Terrence SpencerParticipantJeff, thanks for those links.
Please correct my assumptions.
When using the conduit without cell, it will always be in dhcp client mode so it can receive an ip address as well as gateway and dns addresses (or statically assigned).
When would the 2.1 address ever be used, as the conduit will always be connected to a network to gain a gateway and 192.168.2.1 will most likely not be on the current network.
I configured the conduit for dhcp client, and hooked it up to my router and saw where it got an ip address. I was unable to connect to the conduit with the assigned address.
Thank you for your help.
February 17, 2016 at 11:48 am #11688Jeff HatchKeymasterTerrence,
>>When using the conduit without cell, it will always be in dhcp client mode so it can receive an ip address as well as gateway and dns addresses (or statically assigned).
When you configure the Ethernet interface in the WEB UI, you can enable the DHCP client to get and address, gateway and DNS. If you choose static, you will need to configure the interface IP, the gateway, and the DNS yourself. If DHCP client is enabled, the Conduit must be connected to a network with a DHCP server available.
>>When would the 2.1 address ever be used, as the conduit will always be connected to a network to gain a gateway and 192.168.2.1 will most likely not be on the current network.
If DHCP client is enabled, the 192.168.2.1 address will not be used. The interface should not get configured with an address by the system until a DHCP response is received that provides the DHCP lease with the address and other information. You would use the 192.168.2.1 static address if you were connecting directly to the Conduit from your PC (a cable going directly from an Ethernet card in your PC and plugged into the Conduit).
>>I configured the conduit for dhcp client, and hooked it up to my router and saw where it got an ip address. I was unable to connect to the conduit with the assigned address
Can you ping the Conduit address from your PC or whatever you’re trying to connect to it with? Have you accessed the Conduit via the debug console to verify that the address is in fact assigned (use ifconfig -a)?
Jeff
February 17, 2016 at 1:08 pm #11690Terrence SpencerParticipant>>Can you ping the Conduit address from your PC or whatever you’re trying to connect to it with? Have you accessed the Conduit via the debug console to verify that the address is in fact assigned (use ifconfig -a)?
I was unable to ping the device, although the router showed the ip address on lease to the Conduit.
So is there a way to get to the debug console with the usb cable?
I will have to dig up a db9 cable if not. My slate that I develop with does not have a db9 connection. Maybe the docking station does.
February 17, 2016 at 6:54 pm #11691Terrence SpencerParticipant>>So is there a way to get to the debug console with the usb cable?
>>I will have to dig up a db9 cable if not. My slate that I develop with does not have a db9 connection. Maybe the docking station does.Boy, I don’t know where I got the db9 idea? Must be another product I am working on.
Yes there is a usb interface on the front panel behind the secret door.
February 17, 2016 at 7:04 pm #11692Terrence SpencerParticipantI am configuring several conduits.
on the AEP model when in Packet Forwarding mode to “TheThingsNetwork”, what should “server_address”: and gateway_ID”: be?is gateway id the id of my conduit?
Is the server address the TheThingsNetwork server address?Thank you for your help.
“gateway_conf”: {
“synch_word”: 52,
“forward_crc_disabled”: false,
“forward_crc_error”: true,
“forward_crc_valid”: true,
“gateway_ID”: “<WILL-BE-REPLACED-WITH-LORA-EUI>”,
“keepalive_interval”: 12,
“push_timeout_ms”: 120,
“serv_port_down”: 1780,
“serv_port_up”: 1780,
“server_address”: “us01-iot.semtech.com”,
“stat_interval”: 20
}
}February 18, 2016 at 6:46 am #11694Jason ReissKeymasterThe “gateway_ID” will be auto-populated with an EUI from the MTAC-LORA card installed in the Conduit, so you don’t need to configure that.
If you want to know the EUI value login into the GUI and query the api
https:///api/system/accessoryCards Change “serv_port_down” and “serv_port_up” to 1700 and “server_address” to “croft.thethings.girovito.nl”
You can also change the crc settings if you wish to match the TTN example below. CRC failed messages can be filtered at the gateway, no sense sending them over the internet.
From things network doc:
{ "gateway_conf": { "gateway_ID": *YOUR_OWN_SERIAL*, "serv_port_up": 1700, "serv_port_down": 1700, "server_address": "croft.thethings.girovito.nl", "forward_crc_valid": true, "forward_crc_error": false, "forward_crc_disabled": true } }
February 18, 2016 at 8:49 am #11697Terrence SpencerParticipantJason, thanks for that config info.
-
AuthorPosts
- You must be logged in to reply to this topic.