This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Openplotter + MQTT + Dashboard

I wanted to ask this in the forum, but I couldn't find that anywhere.

I've built a simple GPS nodule by connecting an Adafruit Ultimate GPS to an Arduino MKR1000. That should connect over WiFi to a Raspberry Pi 3 running OpenPlotter 0.8.0.

So far, I have the Arduino connecting to the Pi 3 with the wifi access point started from the OpenPlotter configuration panel. There, it is also indicated that there is an MQTT broker that I might connect to, with the IP addresses indicated on the right. There is no information on what (if any) access credentials would be required.

However, trying to connect, nothing happens. I manually started a mosquitto broker via the terminal, and that works fine (so it looks like the port numbers for MQTT are not reserved by another process).

So is it true that the MQTT broker needs to be started manually, that there is no configuration preset for that? Secondly, do I need to subscribe to that same MQTT server via the "MQTT" tab on the OpenPlotter configuration panel, to get any SignalK messages to OpenPlotter?.

I`m now on OP10 and it looks for me that you need to hit the "play" button on the desktop to start mosquitto...
(Dont know why this play button is there, wouldnt it be better to run all at boot?)

Needs to be adaptet for the documentation also its gnu lizense! is a good broker

Shure the Dokumentation is in german and there are 3 parts

MQTT Introduction
Table of Contents
1.1 What is it?
1.2 Basic structure
1.3 This is how MQTT ticks
1.4 Order in the chaos
1.5 What can you do with it now?
1.6 Ah, yes. And what is great about it?
1.7 Still, why is it so great?
1.8 Cool, what do you need?
1.9 Disadvantages
1.9.1 Single Point of Failure
1.9.2 Security Username / Password TLS
1.9.3 Changing the topic hierarchy
1.9.4 Network Traffic
1.10 outlook
1.10.1 QoS
1.10.2 Retained Messages
1.11 Links
Message Queue Telemetry Transport

What's this?
It is a protocol to transfer data among different devices. MQTT works eg via a TCP / IP connection. (For those who want to post something verbal: one calls the M2M, Machine to Machine, otherwise MQTT is a transport protocol.)

Basic structure
The heart of the MQTT network is a broker. The devices connected to the broker are called clients for simplicity. (Not quite right, but later we get to know more)

So ticks MQTT
We simply write / send a message to the broker. If you pick up and read the message, you will not be interested at all. This is one of the great advantages.

Order in the chaos
What is the advantage? And how can someone read a message? This is where MQTT's refined concept starts: We do not simply provide data to the broker. We also organize them ourselves. The magic word for this is called "Topic". You can imagine something like a directory tree under Windows, or like a file on a web server. Another picture for a "topic" would be a kind of bulletin board.
A topic could be this: at home / 1OG / kitchen / light / state
This topic would make it possible to re-write the state of the kitchen light on the first floor.
Our small smart light switch could always record the current state of the light in this topic. In "MQTT-Speaking" one would say our client is a publisher. He publishes information.
Let us take a sensor: at home / 1OG / kitchen / fridge / temperature / state
That would be a nice topic for a temperature sensor in the refrigerator. Here, too, we would be dealing with a publisher.
It is important that we do not have to worry about the technology. We also have a lot of free hands in organizing the topics.

What can you do with it now?
Now let's see the refrigerator temperature on a display. Maybe we store sensitive medicines in the refrigerator and have children who like to leave the refrigerator door open?
So we take a display and pinch it to our broker. But now we do not want to publish the temperature, that is the sensor. We want to read them. So we report to the broker with the display and "subscriben" the topic. We inform the broker that this information is of interest to us.
So our display subscribes to the temperature. In future, the broker will always try to communicate the temperature to our display.

Ah yes. And what is great about it?
Well, as we programmed the thermometer, we did not know anything about the display. We do not have to change anything on the thermometer either. This remains the way it is.
If we now want to have another display, we are just building a second display and subscriben the topic also with the broker. In the future, he will send the information to both displays.
If we want a graphical evaluation of the temperature profile, then we could subscribe the topic to the broker with FHEM. Temperature get, write in logfile, plot, finished.

Still, why is it so great?
Well, when designing MQTT, it is important to be able to manage without great resources. This means that for many "Bastelhardware" (Arduino etc.) there are ready libraries. I'll show you later. Also, anyone who likes to javascript, java, Perl, Python, finds well functioning libraries. For the "ambitious hobbyist" this means: We can build and program devices that communicate with each other independently. A button that turns on the light on a remote actuator is not a problem. Without burdening FHEM or even needing it. So we can very quickly read and evaluate our refrigerator temperature with various programming languages ​​on a myriad of devices.

Cool, what do you need?
An MQTT broker; Eg Mosquitto. For the microcontroller of your own choice a suitable library. For Arduino, the PubSubClient would offer Ggfs. An analysis tool such as MQTT.fx

Single Point of Failure
Where light is, as is known shadows. For us, as we use FHEM to house control, the first question is, why one does not simply connect its devices directly to FHEM, but first sets up an MQTT broker (ultimately a piece of software) in front of it. Possible reason: MQTT is better than any self-knit protocol. It is even ISO standard. There are many tools and aids for this; Own intelligence to teach the devices is also quite simple.

In principle, MQTT is just as secure as a postcard. As long as you do not extra secure, anyone who is in his own LAN (and the address of the broker knows) can read all the topics. My house / hall / doorstep: open / close Is not really smart! Remedy:
Username / Password
First you can assign a Username / Password. Since it is synonymous for a long time not sure, but at least it increases the effort already times. Now you have to sniff at least once packets and understand, unauthorized to read or even to publish.
!!!!!!!!!!!!!!!!!!!!!!!!To be really safe, no way leads to TLS. Unfortunately, for example, an Arduino simply can no longer. Somewhere the memory and the computing power then noticeable.
Change the topic hierarchy
!!!!!!!!!!!!!!!!!!!!!!!!!!Yes that is a problem. If you want to change the hierarchy of the topics, you will rarely get around to adjust your program code (Arduino ..,), re-compile it and upload it again. The same applies if, for example, the IP address of the broker changes.
Network Traffic
Another question you can ask yourself is a basic one: What is the purpose of having to network your network (especially WLAN) with such things as sensor data. This is not completely unjustified.
!!!!!!!!!!!!!!!!!!!MySensors is probably a much better choice for many small battery-powered sensors. Integrating sensors with batteries into a WLAN is technically a real challenge. The great advantage, however, is that one can easily expand its WLAN in the case of the Reichsendende. WLAN repeater, thing good.
Here ends only the short overview. If you are curious, you can look forward to many more exciting topics:
Another feature is the QoS Level of MQTT.
* QoS Level 0: is a kind of fire and forget. Whether the data arrive is not checked further
* QoS Level 1: guarantees the delivery of the message; But it can also happen that a message is sent and received more frequently
* QoS Level 3: This ensures that every message arrives at the recipient's exact address
Retained Messages
Also a funny thing, we get to know later. But one example I would like to describe already: We later tinker the above-mentioned temperature sensor and the associated display. This is expanded by a flashing LED when a certain temperature is exceeded. Quizquery: from where does the display know the desired threshold? Of course you could put it in the program code. But then it is hard-wired. If we just would publish it normally, the display would only know him if the threshold value was popped after the display was connected to the broker ... Here are retained messages. These are also sent when connecting a subscriber, although there was no change.
Official homepage of MQTT, English
Very good introduction, English, are 5 readable parts
An excerpt from Heise with examples, deusch, very readable
MQTT FX - a very useful analytical tool
Discussion forum in the forum
Part 2 of the MQTT introduction, heavier food
I can not enable MQTT publishing from openplotter, there is the guide for earlier versions but not for the current version of the software (11.7).
Is it possible to have step-by-step guidance?
(2017-05-18, 08:31 PM)kste Wrote: I can not enable MQTT publishing from openplotter, there is the guide for earlier versions but not for the current version of the software (11.7).
Is it possible to have step-by-step guidance?

I suggest for the developers to think about in general to put the developement not to a higher level for an official beta until not a documentation exists.

the project is very good as far i can see but actively working people for the documentation is necessary. i did offer my help to translate to german on a regular base. i did need approx one month to translate the dokumentation to german.

My test is now that my wife i push to make the romanian language and she is a computer noob and do not speak any english.

and i have someone that never saw a raspberry pi before. he is clever in IT things because he works as a manager in it business.
he does not speak english or not so much trained. What a surprize yesterday with the new version that with raspberry pi v3 the wifi was not working from second wifi.

i myself go to command line in the terminal if such happens but not someonenew to a raspi ????

in 0.9 works wifi from scratch

i let him find out himself and he needs 30 minutes with try and error.
The version that he is speaking about is clearly marked Alpha. It is ridiculous to expect an alpha version to have full documentation. Alpha versions are known to be unstable and for features to not work as previous versions did. With that said, this is not the proper thread in the Forum to talk about bugs or documentations​. This Thread is clearly labeled MQTT and is under the brag board section where people are supposed to show off their work.

Sent from my SM-G955U using Tapatalk
I am fully aware about this. And because I am not a programmer but familiar with FHEM where is used Perl not phyton I will go the way for my private installation to use FHEM for special things
Something like as a proof of concept.

I blog with Robin in German language and every week the people get a nice simple project how to make something

This was a frame used 433 Hz

This frame is running since 2 years without problems

For me in case of mqtt it's more easy to run it with my usual system and write from time to time some ideas. Just to pick them up if you run my sensors or other things since years than I try to run it also with openplotter. Such a Projekt takes me to push in the block approx 4 hours in German. For a reasonable translation and than its not a good translation to English I personally need 2 days

Gesendet von meinem SM-G900F mit Tapatalk
You are right Vamonos, this is not the right thread here, I apologize, it was just the only recent tread where talk about MQTT.
Now I have posted here:
I have to apologise also because I was not clear in Tapatalk where I am in the forum. Just did appear.

Gesendet von meinem SM-G900F mit Tapatalk
No worries guys. It just helps you get the correct answers when posted in the proper area.

Sent from my SM-G955U using Tapatalk

Forum Jump:

Users browsing this thread: 1 Guest(s)