Open diego-gv opened 5 years ago
My proposal is to follow this example:
Type1: {
service: 'service',
subservice: '/servicepath',
attributes: [
{
'name': 'temperature',
'type': 'Number'
}
],
internalAttributes: {
lorawan: {
application_server: {
host: 'mosquitto',
username: 'user',
password: 'password',
provider: 'loraserver.io',
options: {
port: 1883,
clientId: 'MQTT_client1',
ca: fs.readFileSync('docker/certs/ca.pem'),
cert: fs.readFileSync('docker/certs/mqtt-client.pem'),
key: fs.readFileSync('docker/certs/mqtt-client-key.pem'),
rejectUnauthorized: true,
protocol: 'mqtts'
}
},
app_eui: '**************',
application_id: '****'
}
}
},
This type of configuration allows us to play with the MQTT's configurations. We would have to describe the MQTT broker for each type, but this is a simple solution.
An other hand, I tried to write simple tests to check my implementation, but because of my experience like Javascript developer is limited (I'm mainly Python Developer) I don't know very well how to do it and I'm still looking for a correctly way to implement it following the tests already done by you.
I'm sorry for the possible inconveniences.
Hello!
I have been looking at my previous proposal and I have decided to change the way in which certificates are indicated. In this case we will have to indicate the certificates as a list of ASCII numbers.
options: {
port: 1883,
clientId: 'MQTT_client1',
ca: [45,45,45,45,45,66,69,71,73,78,32,67,69,82,84,73,70,73,67,65,84,69,45,....],
cert: [45,45,45,45,45,66,69,71,73,78,32,67,69,82,84,73,70,73,67,65,84,69,.....],
key: [45,45,45,45,45,66,69,71,73,78,32,82,83,65,32,80,82,73,86,65,84,69,32,.....],
rejectUnauthorized: true,
protocol: 'mqtts'
}
This way , for example, we could send the certificates in a Device Provisioning by means of a POST request from Postman.
In addition, in the static provisioning we can continue indicating the certificates as indicated above (as a file).
Bests regards
Hi @garvi-x,
First of all, sorry for the delay to review this PR.
In principle, I am OK with your proposal, but I don't like too much the last change to indicate the certificates as a list of ASCII numbers.
I would prefer to use the first option and pass the certificates using a volume.
What do you think?
Hi @dcalvoalonso,
My proposal is that we can have both options, certificates in a volume and as a list of ASCII numbers.
The first option is for static provisioning, while the second option is for device and service provisioning. Since certificates in a volume are not available from outside using, for example, Postman.
Hi I am fairly new to this and wanted to use the LoRaWan-IoT-Agent with an existing LoRaServer.io I can get my hands on. Did you manage to provision a device with your method?
The mqtt-server uses a root signed CA and mqtts. Also the mqtt-broker needs user credentials to log on and the port needs to be 8883. Is there any headway with this? To be honest I am a bit lost, for all I get is an empty response after what I think is a timeout.
Hi @StWiemann,
The method that I used for device provisioning was the same that it is explain in the documentation of this project in this link: https://fiware-lorawan.readthedocs.io/en/latest/users_manual/index.html
On the other hand, I am not a expert in this materia, only I have read the documentation of LoRaWAN IoTAgent and LoRaServer.io for deployment my scenary.
I hope I helped you.
Thanks @garvi-x, I managed to connect to my own mqtt-broker by using the iotagent-json instead with some additional environmentals:
- IOTA_MQTT_HOST=hostaddress.de # The host name of the MQTT Broker
- IOTA_MQTT_PORT=8883 # The port the MQTT Broker is listening on to receive topics
- IOTA_MQTT_PROTOCOL=mqtts
- IOTA_MQTT_USERNAME=Mqtt-Account
- IOTA_MQTT_PASSWORD=Mqtt-Password
That works for me as a starting point. LoRaWAN might come later.
@garvi-x Maybe Base64 would be the better option. https://nodejs.org/api/buffer.html#buffer_class_method_buffer_from_string_encoding
@diego-gv
can you rebase your changes to the current up-to-date code base? thx
@diego-gv
can you rebase your changes to the current up-to-date code base? thx
Tell me any question or change that you consider appropriate.
I have also added the standart gitignore file for javascript projects.