Problems getting started with Mainflux

[Mario Fischer]

Hello everyone!

I am new to Mainflux and I like the lightweight concept very much compared to heavy solutions like DeviceHive.

Please give me some rope here as these are my first steps with Mainflux. I have a few questions because I have already hit some roadblocks:

1. As recommended I worked through the "Getting Started" guide, setting up Mainflux using Docker Compose, adding an account, a client, a channel and credentials. This works as expected. But when I try to send a message to a channel by doing

curl -s -S -i --cacert docker/ssl/certs/mainflux-server.crt --insecure -X POST -H "Content-Type: application/senml+json" -H "Authorization: <client_token>" https://localhost/http/channels/<channel_id>/messages -d '[{"bn":"some-base-name:","bt":1.276020076001e+09, "bu":"A","bver":5, "n":"voltage","u":"V","v":120.1}, {"n":"current","t":-5,"v":1.2}, {"n":"current","t":-4,"v":1.3}]'

I get HTTP code 500 (internal server error). I have also tried WebSockets (with the AdvancedRestClient tool), but I cannot connect to

wss://localhost/channels/<channel_id>/messages?authorization=<client_auth_key>

Of course I have replaced the channel id and authorization key placeholders.

What is my mistake here?

2. The description says something about "protocol bridging" with MQTT as an example. I cannot find anything about MQTT in the documentation.

My ultimate goal is to talk to the connected devices by MQTT. Is this already possible?

3. I want to run Mainflux on a Raspberry Pi. Best case scenario would be using Docker to run the Mainflux stack on the RPi. How should I approach this?

Thank you!

Greetings,
Mario

[Drasko DRASKOVIC]

Hi Mario,

On Tue, May 29, 2018 at 1:12 AM, Mario Fischer <lostma...@gmail.com> wrote:
> Hello everyone!
>
> I am new to Mainflux and I like the lightweight concept very much compared
> to heavy solutions like DeviceHive.

Thanks for your interest in Mainflux.

>
> Please give me some rope here as these are my first steps with Mainflux. I
> have a few questions because I have already hit some roadblocks:
>
> 1. As recommended I worked through the "Getting Started" guide, setting up
> Mainflux using Docker Compose, adding an account, a client, a channel and
> credentials. This works as expected. But when I try to send a message to a
> channel by doing
>
> curl -s -S -i --cacert docker/ssl/certs/mainflux-server.crt --insecure -X
> POST -H "Content-Type: application/senml+json" -H "Authorization:
> <client_token>" https://localhost/http/channels/<channel_id>/messages -d
> '[{"bn":"some-base-name:","bt":1.276020076001e+09, "bu":"A","bver":5,
> "n":"voltage","u":"V","v":120.1}, {"n":"current","t":-5,"v":1.2},
> {"n":"current","t":-4,"v":1.3}]'
>
> I get HTTP code 500 (internal server error). I have also tried WebSockets
> (with the AdvancedRestClient tool), but I cannot connect to
>
> wss://localhost/channels/<channel_id>/messages?authorization=<client_auth_key>
>
> Of course I have replaced the channel id and authorization key placeholders.
>
> What is my mistake here?

This should be working. It is potentially wrong channel nb, wrong
token (did you use correct device token), or maybe malformed SenML.

But most probably you did not connect your device to this channel.

You can try listing (GET-ing) the channel and see if your device is in
the "connected" list:
https://mainflux.readthedocs.io/en/latest/getting-started/#access-control

>
> 2. The description says something about "protocol bridging" with MQTT as an
> example. I cannot find anything about MQTT in the documentation.
>
> My ultimate goal is to talk to the connected devices by MQTT. Is this
> already possible?

Mainflux lets you talk over all supported protocols. You PUB on an
arbitrary protocol, and SUB on another on - you will get the messages,
as Mainflux does all message bridging internally.

For some reason latest docs were not rebuilt. I have kicked the build
again, now you should see MQTT related stuff.

>
> 3. I want to run Mainflux on a Raspberry Pi. Best case scenario would be
> using Docker to run the Mainflux stack on the RPi. How should I approach
> this?

Best approach will be to build everything for ARM.

Take a look at the Makefile and pass it the adequate ENV variables:
https://github.com/mainflux/mainflux/blob/master/Makefile#L8

Something like this:

GOOS=linux GOARCH=arm GOARM=7 make

should do the trick.

Also, take care that MQTT broker is NodeJS-based for now, so you can
install it on RPi as a classical NodeJS app (via `npm install`).

Additionally, you will need to install PostgreSQL and NATS broker
(https://nats.io/), and add at least one DB for messages - for example
InfluxDB. There is also MongoDB support coming soon:
https://github.com/mainflux/mainflux/pull/307

Best regards,
Drasko

[Mario Fischer]

Hi Drasko,

This should be working. [...]

I forgot to mention that I used the latest release version 0.3.0 of Mainflux instead of the current master branch. I just cloned the repo and tried the steps again, but I failed even earlier.

Here are my results:

https://gist.github.com/fischermario/e2c254ec927cbf3ca9c65e19a9b07bdf

Was it a bad idea to try out the master branch? What went wrong here?

 

For some reason latest docs were not rebuilt. I have kicked the build
again, now you should see MQTT related stuff.

Thank you very much for that. I found out that the docker-compose file in the 0.3.0 release of Mainflux does not contain any mention of an MQTT adapter, but the current master branch does. That is why I tried that one out.

Best approach will be to build everything for ARM. [...]

Thanks again for your insight. I also found out that most of the required third-party components provide Dockerfiles that support arm32v7 architecture which is suited for the RPi. I hope that will make things easier. I will try it out in the next few days.

Greetings,

Mario

[Drasko DRASKOVIC]

Hi Mario,

On Tue, May 29, 2018 at 11:55 AM, Mario Fischer <lostma...@gmail.com> wrote:
> Hi Drasko,
>
>> This should be working. [...]
>
>
> I forgot to mention that I used the latest release version 0.3.0 of Mainflux
> instead of the current master branch. I just cloned the repo and tried the
> steps again, but I failed even earlier.
>
> Here are my results:
>
> https://gist.github.com/fischermario/e2c254ec927cbf3ca9c65e19a9b07bdf
>
> Was it a bad idea to try out the master branch? What went wrong here?

`clients` were renamed to `things` in latest release, please take a
look at this PR: https://github.com/mainflux/mainflux/pull/318/files
that will correct the doc.

>
>>
>> For some reason latest docs were not rebuilt. I have kicked the build
>> again, now you should see MQTT related stuff.
>
>
> Thank you very much for that. I found out that the docker-compose file in
> the 0.3.0 release of Mainflux does not contain any mention of an MQTT
> adapter, but the current master branch does. That is why I tried that one
> out.

Yes, MQTT adapter was not in the monorepo before, we are trying to
release official 0.4 any day now.

You can use `latest`, it will become 0.4.

>
>> Best approach will be to build everything for ARM. [...]
>
>
> Thanks again for your insight. I also found out that most of the required
> third-party components provide Dockerfiles that support arm32v7 architecture
> which is suited for the RPi. I hope that will make things easier. I will try
> it out in the next few days.

Great to hear this.

Keep us informed of the progress, we are very interested in this RPi port!

Best regards,
Drasko

[Mario Fischer]

Hi Drasko,

thanks for your quick response!

`clients` were renamed to `things` in latest release

That was it.

 

Keep us informed of the progress, we are very interested in this RPi port!

I will certainly do!

Some other things I noticed are:

1. Yesterday I have tried to connect to the channel via WebSocket again (I am now using the master branch), but got the same result with AdvancedRestClient tool ("Unknown error occurred"). I have used the following URL:

wss://localhost/channels/<channel_id>/messages?authorization=<client_auth_key>

I have also checked that the mainflux/ws:latest container is running and port 8186 is forwarded to external. What am I missing?

2. The behavior of Mainflux has changed when it comes to creating new clients and channels. Calling

https://localhost/clients -d '{"type":"device", "name":"weio"}'

with version 0.3.0 resulted in

Location: /clients/7318ede9-40f9-48d3-89f3-ca001843e2fb

while calling

https://localhost/things -d '{"type":"device", "name":"weio"}'

with the current master branch results in

Location: /things/1

Is this intentional behavior (things and channels now numbered consecutively)?

3. I have created a user, but Dashflux declines any login attempt. Even if I enter false login data the result is always "server side error". Is Dashflux still "under construction"?

4. Btw. MQTT works great! ;-)

I also have some questions about the architecture of Mainflux and client provisioning, but I want to get more comfortable with the system before asking.

Greetings,

Mario

[Drasko DRASKOVIC]

On Wed, May 30, 2018 at 8:51 AM, Mario Fischer <lostma...@gmail.com> wrote:
> Hi Drasko,
>
> thanks for your quick response!
>
>> `clients` were renamed to `things` in latest release
>
>
> That was it.
>
>>
>> Keep us informed of the progress, we are very interested in this RPi port!
>
>
> I will certainly do!
>
> Some other things I noticed are:
>
> 1. Yesterday I have tried to connect to the channel via WebSocket again (I
> am now using the master branch), but got the same result with
> AdvancedRestClient tool ("Unknown error occurred"). I have used the
> following URL:
>
> wss://localhost/channels/<channel_id>/messages?authorization=<client_auth_key>
>
> I have also checked that the mainflux/ws:latest container is running and
> port 8186 is forwarded to external. What am I missing?

Aleksandar (in CC) can give more details on WSS.

>
> 2. The behavior of Mainflux has changed when it comes to creating new
> clients and channels. Calling
>
> https://localhost/clients -d '{"type":"device", "name":"weio"}'
>
> with version 0.3.0 resulted in
>
> Location: /clients/7318ede9-40f9-48d3-89f3-ca001843e2fb
>
> while calling
>
> https://localhost/things -d '{"type":"device", "name":"weio"}'
>
> with the current master branch results in
>
> Location: /things/1
>
> Is this intentional behavior (things and channels now numbered
> consecutively)?

Yes, intentional. We are not using SW generated UUID4 as it can lead
to inconsistency in scalable deployments. We now leverage on DB
(PostgreSQL) generaled serial nubers, which guarantee that there is a
unique ID for each entity cluster-wide.

>
> 3. I have created a user, but Dashflux declines any login attempt. Even if I
> enter false login data the result is always "server side error". Is Dashflux
> still "under construction"?

It might be a bug, but I'll let Dusan fill in the details. Also, if
bug is confirmed it would be beneficial to open the issue.

Note that Dashflux is not yet integrated in the release, and thus not
yet officially supported. It is in early development phase today.

>
> 4. Btw. MQTT works great! ;-)

Glad to hear this.

>
> I also have some questions about the architecture of Mainflux and client
> provisioning, but I want to get more comfortable with the system before
> asking.

Please send us all suggestions and questions, we are glad to help.

Best regards,
Drasko

[Dušan Borovčanin]

среда, 30. мај 2018. 08.51.39 UTC+2, Mario Fischer је написао/ла: 

Hi Drasko,

thanks for your quick response!

`clients` were renamed to `things` in latest release

That was it.

 

Keep us informed of the progress, we are very interested in this RPi port!

I will certainly do!

Some other things I noticed are:

1. Yesterday I have tried to connect to the channel via WebSocket again (I am now using the master branch), but got the same result with AdvancedRestClient tool ("Unknown error occurred"). I have used the following URL:

wss://localhost/channels/<channel_id>/messages?authorization=<client_auth_key>

I have also checked that the mainflux/ws:latest container is running and port 8186 is forwarded to external. What am I missing?

2. The behavior of Mainflux has changed when it comes to creating new clients and channels. Calling

https://localhost/clients -d '{"type":"device", "name":"weio"}'

with version 0.3.0 resulted in

Location: /clients/7318ede9-40f9-48d3-89f3-ca001843e2fb

while calling

https://localhost/things -d '{"type":"device", "name":"weio"}'

with the current master branch results in

Location: /things/1

Is this intentional behavior (things and channels now numbered consecutively)?

3. I have created a user, but Dashflux declines any login attempt. Even if I enter false login data the result is always "server side error". Is Dashflux still "under construction"?

Yes, Dashflux is under construction, but these basic features should be working. Can you, please, check your URL? Dashflux is served at https://localhost/ as well as https://loclhost:3000. You should use URL with no port since that one is using NginX reverse proxy. Otherwise, if you access Dashflux using URL with port, Dashflux won't be able to access Mainflux services and you'll get an error;