MQTT sensor connection example implementation

[toqduj]

Based on a request by @tkurki (requested in this comment in #288 ), here's one possible implementation for letting sensors send information over Wifi & MQTT to the SK receiver.

A short summary: I've created a straightforward GPS sensor (for deck mounting) by connecting an Adafruit Ultimate GPS (based on the MTK3339 chip) to an Arduino MKR1000 and a LiPo back-up battery. The code for running the sensor is available here. It is not advanced code, but it is simple and works.

The code uses the following key libraries alongside standard ones:

• PubSubClient for MQTT, modified to handle larger messages
• ArduinoJson for constructing the SK deltas
• PString for handling the JSON string before sending.
• TinyGPS++ for interpreting the GPS messages

The sensor module "sender" connects to a "receiver", a Raspberry Pi running OpenPlotter V0.9 (OP) in the following steps:

1. The sensor connects to the OP-instantiated Wifi access point, currently using hardcoded information (SSID, WPA password).
2. The sensor connects to the OP-instantiated Mosquitto MQTT server, currently using hardcoded information (IP, port, MQTT username, MQTT password). Once I find a compatible mDNS discovery library, the IP and port can be autofound.
3. The sensor subscribes to an MQTT channel, "gpsget", set up for this purpose.
4. The sensor outputs SK deltas to this channel, updating one variable per message (five messages in total for five navigation keys: position.latitude, position.longitude, position.altitude, speedOverGround, and courseOverGroundTrue). Due to the design of ArduinoJson, I could not get it to put multiple key:value combinations in a single message. Each message is about 160 bytes long, and contains the following information (which adheres to the SK delta format as far as I could understand):

{ "updates": [{ "source": { "timestamp": "2016-11-09T09:15:36Z", "$source": "deck.gps001" }, "values": [{ "path": "navigation.speedOverGround", "value": 0.8385444 }] }] }

The timestamp is the time which the GPS returns, i.e. the time when the reported values were valid, and so lags a little behind real time.

Currently, OpenPlotter does not parse incoming SK deltas yet, as explained by @sailoog in this comment. For now, I am waiting for that to be implemented, as MQTT appears to be a nice way of sending information.

There is a power-saving feature: if the GPS does not have a valid fix, the Wifi disconnects. Every time before sending a message, it is checked if Wifi and MQTT are connected (otherwise it reconnects). As such, it uses on average about 50-60 mA at 5V (0.3W). This can be reduced in the future by exploiting the built-in RTC as a watchdog timer.

[pod909]

No hello and no time in the connect. So we would be back to putting "age" on the Delta, or just recognising this as a weakness of MQTT

[toqduj]

Good question. In the case of the GPS sensor it doesn't really matter as it carries its own calibrated time. However, this can be a problem for non-GPS-equipped sensors.

This sensor only sends information, it does not receive or interpret any messages. That means that the code becomes a lot simpler, but has the drawback that it cannot synchronise timestamps. The question is if it should, and if so, if it can request a timestamp from the receiving station.

On Wed, Nov 9, 2016 at 12:20 PM, pod909 notifications@github.com wrote:

No hello and no time in the connect. So we would be back to putting "age" on the Delta, or just recognising this as a weakness of MQTT

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SignalK/specification/issues/291#issuecomment-259391534, or mute the thread https://github.com/notifications/unsubscribe-auth/AFMoycLEsx8AgWubpinu8EFsYYCjII7Iks5q8axpgaJpZM4KtV6- .

[pod909]

Bad idea to start plugging holes in the protocol. Either it's a desired feature and MQTT is not a documented protocol or we specify the Delta to accept the limitations of the protocol.

I think timestamp should only be included in any Delta message where the sender can establish and send real time from a network time server or where a hello has been sent.

That limits the use with MQTT to recognize the limitations in the protocol.

[tkurki]

In my head MQTT and Signal K have several, slightly different connections:

1. MQTT enabled "sensor": MQTT to Signal K Gateway functionality. Something that produces data that might be useful when included in a SK data stream and can use MQTT to publish it. Examples include environmental sensors: temperature, humidity, air pressure. Is there value in documenting how a sensor with MQTT client capability should connect to a MQTT-to-SignalK gateway? In practice this would saying that _One should be able to publish values to topics in the form /vessels/self/environment/outside/temperature in SK standard units (Kelvins in this case)`. This could be documented as an (optional) feature of a fully loaded SK server.
2. Signal K to MQTT Gateway. If I should like to use an cloud data logger that is an MQTT server can I just enter the server's address and turn this on? Maybe a SK server plugin that allows you to publish all or some of the data to an MQTT server, so that when the SK server gets a new value for /vessels/self/environment/outside/temperatureit would publish the value to a remote MQTT topic of the same name.
3. MQTT as SK delta carrier. Publish the local vessel's data as SK deltas to a cloud broker's topic /vessels/<UniqueVesselId>/signalk/delta, allowing one to leverage a highly scalable cloud MQTT broker. Think Vendee Globe deltas from all the participating boats, piped to race tracker apps in browser on phone/pad/computer.

I have no first hand experiencewith MQTT so I am not the best person to comment here - maybe there are other use cases where the two tie together naturally. I invite people with more experience to share their views on this - especially @sailoog with Open Plotter MQTT and Signal K capabilities.

[tkurki]

@pod909 I think you are overemphasising timestamp accuracy here. Not all data is very time accuracy sensitive. Stuff like electricity (voltage, current) and environment need not be sampled very frequently nor accurate down to microsecond - in this case it is perfectly ok if my SK server acting as a MQTT to SK gateway assigns the timestamp as it receives data from a MQTT sensor. Same thing for a MQTT logging service - it assumes that the data it receives (just a value, not a delta message, so no timestamp) is about "now".

[pod909]

Possibly, hence the suggestion that it may not be used, or may be used with a RTC. But also allowing for data for none RTC sensors to still be time synconused accurately

On Nov 9, 2016 5:54 PM, "Teppo Kurki" notifications@github.com wrote:

@pod909 https://github.com/pod909 I think you are overemphasising timestamp accuracy here. Not all data is very time accuracy sensitive. Stuff like electricity (voltage, current) and environment need not be sampled very frequently nor accurate down to microsecond - in this case it is perfectly ok if my SK server acting as a MQTT to SK gateway assigns the timestamp as it receives data from a MQTT sensor. Same thing for a MQTT logging service - it assumes that the data it receives (just a value, not a delta message, so no timestamp) is about "now".

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SignalK/specification/issues/291#issuecomment-259479338, or mute the thread https://github.com/notifications/unsubscribe-auth/AF0KFznVfBpMmTbLmsorpBgxcOLBb-jtks5q8gjZgaJpZM4KtV6- .

[tkurki]

As MQTT is typically used for transmitting sensor data as plain numbers encoded as strings (my use cases 1 and 2 above) the only thing that is transmitted is the value - there is no way to include timestamp.

See for example https://home-assistant.io/blog/2015/10/11/measure-temperature-with-esp8266-and-report-to-mqtt/

In case 3 we are using MQTT to transmit SK deltas. How the delta is generated and where the timestamp comes is not related to using MQTT to transmit the delta.

[sailoog]

This is how we are implementing MQTT in OP v0.9.0

OP has a built in broker and you can define a remote broker too. All publication in any topic will be managed by both brokers at the same time to communicate with the built in and remote dashboards. We want mqtt to be used not only for signal k data but for any string or number value. When you set topics in MQTT tab, you select the type of data (delta signal k or others). The latter is not implemented yet in the screenshot below.

Receiving If you have set the topic to delta signal k type, received data will be added directly to the signal k full data model as any delta message. If you have set the topic to others, we will store values in the full data model using notifications key:

notifications.mqtt.foo.message.value notifications.mqtt.foo.$source notifications.mqtt.foo.timestamp notifications.mqtt.foo.bar.message.value notifications.mqtt.foo.bar.$source notifications.mqtt.foo.bar.timestamp

Triggers and actions will be created for these topics in the built in Actions system to interact with them. Yes, I know this is not an orthodox use of notifications key but it works for us.

Sending On the other hand, when you send data by the Actions system through all the possible ways (email, SMS, Twitter, MQTT...) you can choose from several options: custom string/numbers, selected signal k values from full data model or sending signal k delta messages.

In this way we ensure that the MQTT system can interact with all MQTT phone apps, web dashboards... using signal k or whatever type of data.

[toqduj]

I wouldn't go so far and say that all MQTT traffic from a sensor must contain only unlabelled "plain" values; the MQTT messages from my sensor are sent as SK deltas with timestamps and path information (navigation.position.latitude, for example), which is useful as the same sensor can send multiple pieces of information. It would be quite cumbersome to set up an MQTT topic for each value. Defining what messages sent from sensors should look like so they can be ingested by the receiver into the full SK set would be useful.

I agree with the optional timestamp. Sensors which are very time-sensitive should include timestamps, others can have it added by the receiver. For sensors without an RTC, but which are very time-sensitive (the paddlewheel sensor example comes to mind), we can think of having an NTP daemon installed on the shipboard SK concatenator / OpenPlotter server --hell, we really need to standardise the component names-- to deliver the timestamps. Existing technology, not horribly accurate, but perhaps sufficiently so.

On Wed, Nov 9, 2016 at 8:05 PM, Teppo Kurki notifications@github.com wrote:

As MQTT is typically used for transmitting sensor data as plain numbers encoded as strings (my use cases 1 and 2 above) the only thing that is transmitted is the value - there is no way to include timestamp.

See for example https://home-assistant.io/blog/2015/10/11/measure- temperature-with-esp8266-and-report-to-mqtt/

In case 3 we are using MQTT to transmit SK deltas. How the delta is generated and where the timestamp comes is not related to using MQTT to transmit the delta.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SignalK/specification/issues/291#issuecomment-259497198, or mute the thread https://github.com/notifications/unsubscribe-auth/AFMoyTQCDiWC0CT0ujQQV5BpT8_aJD54ks5q8hmMgaJpZM4KtV6- .

[toqduj]

I think the OpenPlotter MQTT message receiving scheme makes sense as explained by @sailoog above.

On Wed, Nov 9, 2016 at 8:38 PM, Brian P brianpauw@gmail.com wrote:

I wouldn't go so far and say that all MQTT traffic from a sensor must contain only unlabelled "plain" values; the MQTT messages from my sensor are sent as SK deltas with timestamps and path information (navigation.position.latitude, for example), which is useful as the same sensor can send multiple pieces of information. It would be quite cumbersome to set up an MQTT topic for each value. Defining what messages sent from sensors should look like so they can be ingested by the receiver into the full SK set would be useful.

I agree with the optional timestamp. Sensors which are very time-sensitive should include timestamps, others can have it added by the receiver. For sensors without an RTC, but which are very time-sensitive (the paddlewheel sensor example comes to mind), we can think of having an NTP daemon installed on the shipboard SK concatenator / OpenPlotter server --hell, we really need to standardise the component names-- to deliver the timestamps. Existing technology, not horribly accurate, but perhaps sufficiently so.

On Wed, Nov 9, 2016 at 8:05 PM, Teppo Kurki notifications@github.com wrote:

As MQTT is typically used for transmitting sensor data as plain numbers encoded as strings (my use cases 1 and 2 above) the only thing that is transmitted is the value - there is no way to include timestamp.

See for example https://home-assistant.io/blog /2015/10/11/measure-temperature-with-esp8266-and-report-to-mqtt/

In case 3 we are using MQTT to transmit SK deltas. How the delta is generated and where the timestamp comes is not related to using MQTT to transmit the delta.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SignalK/specification/issues/291#issuecomment-259497198, or mute the thread https://github.com/notifications/unsubscribe-auth/AFMoyTQCDiWC0CT0ujQQV5BpT8_aJD54ks5q8hmMgaJpZM4KtV6- .

[tkurki]

It would be quite cumbersome to set up an MQTT topic for each value.

Would it? A MQTT to SK gateway could automatically set up topics for all the SK data model keys - or just create the topic dynamically when somebody connects and then start shoveling incoming values to the SK data model and converting them to deltas.

But position is a good example where one needs a structure to the value, like what is specified in the SK schema for position.

[tkurki]

If you have set the topic to delta signal k type, received data will be added directly to the signal k full data model as any delta message.

So in this case the topic name plays no role and it is just a way to transfer SK deltas? Like my use case 3 above.

[tkurki]

@sailoog what are typical sources of SK deltas that would be using the incoming-delta-over-MQTT functionality?

[sailoog]

So in this case the topic name plays no role and it is just a way to transfer SK deltas? Like my use case 3 above.

Yes

[sailoog]

@sailoog what are typical sources of SK deltas that would be using the incoming-delta-over-MQTT functionality?

The first and unique incoming case was @toqduj one :) but we thought we should be ready to more cases.

[pod909]

mqtt-sn is the variant intended for sensors. MQTT is the general version for publish/subscribe message format for use with a broker.

MQTT doesn't have much to say about the content of the payload provided the message can be ascribed a topic.

The hello message isn't really subscribe content and the hello message can't be included the connect message.

That's not a problem if your timestamp is already synchronized or you don't want to send one.

On Nov 9, 2016 7:05 PM, "Teppo Kurki" notifications@github.com wrote:

As MQTT is typically used for transmitting sensor data as plain numbers encoded as strings (my use cases 1 and 2 above) the only thing that is transmitted is the value - there is no way to include timestamp.

See for example https://home-assistant.io/blog/2015/10/11/measure- temperature-with-esp8266-and-report-to-mqtt/

In case 3 we are using MQTT to transmit SK deltas. How the delta is generated and where the timestamp comes is not related to using MQTT to transmit the delta.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SignalK/specification/issues/291#issuecomment-259497198, or mute the thread https://github.com/notifications/unsubscribe-auth/AF0KF3RH7t8WrqRZEG1GyzugZRSPLsddks5q8hmMgaJpZM4KtV6- .

[toqduj]

@sailoog (regarding this) I used the SK Delta model, as it is specified in the documentation as a valid way of transferring sensor values (here). When I started this, I also found detailed information for sending SK over MQTT/STOMP, so I figured that was the intended way to go (though that information seems to be a bit harder to find now).

@tkurki (regarding this) It's like your case 3, except that the data transfer is from sensor to on-board OpenPlotter computer. Perhaps a case 4?

@pod909 (regarding this) I don't immediately see the need for supporting MQTT-SN (benefits and drawbacks nicely explained here). MQTT-SN appears to be primarily intended for UDP or serial connections, and would require setting up (and agreeing on) unique topic IDs for each topic path. We'd then be going back to NMEA-like identifiers with the associated potential limitations in scope and expandability.

@tkurki (regarding this) That is one way to go about it. I like the general incoming SK topic, but as you indicate, for simpler, non-time-stamped, non-location-aware, single-value-pushing sensors, automatically-generated dedicated topics could be of interest.

[tkurki]

@toqduj My example for case 3 was probably too specific, I believe the SK delta over MQTT is not really dependent on where it is used, be it sensor to onboard server or onboard server to cloud.

However MQTT is designed for connections with remote locations where a "small code footprint" is required or the network bandwidth is limited so its forte may be WAN connections.

[tkurki]

The advantage of topic per SK key approach is that the sending party need not know a thing about Signal K - if the transmitted values are just simple values all you need to worry about is using the correct unit, just configure the topic and start pushing.

Even the unit issue can be amended with automatic conversions by creating topics like /vessels/self/environment/outside/temperature/celsius.

[tkurki]

MQTT doesn't have much to say about the content of the payload provided the message can be ascribed a topic.

This is why I thought prudent to open this issue: the way SK and MQTT are used together needs to be documented to achieve any kind of interoperability and universality.

[toqduj]

This is why I thought prudent to open this issue: the way SK and MQTT are used together needs to be documented to achieve any kind of interoperability and universality.

I propose we use the current implementation as a starting point (following the programming adage: the first implementation defines the standard). @sailoog do you have any opinion about the feasibility of auto-generation of MQTT topics based on the SK schema, as suggested by @tkurki for very simple sensors?

[pod909]

MQTT topics for single values should be the same a the path in the delta

Binary key ids should be derived using the hash function Rob uses in freeboard

[pod909]

Also notifications appear to be undocumented

[pod909]

The topic I'd defined in mqtt-sn is a local I'd defined by the client. It also sends a topic name to I'd mapping so there's no need to regularise topic ids

[rob42]

Ive just caught up on this (sorry, very busy lately) and have some comments. The discussion above covers several subjects: (editing to match @tkurki use cases above) 3) sending signalk messages via MQTT 2) converting arbitrary MQTT data into signalk (aka gateway) 1) using a messagebroker as a gateway by leveraging topics=signalk keys (I like this one)

Another is the broker subscribe process. See https://github.com/SignalK/specification/wiki/Communication-Protocols, which outlines how you can use MQTT/STOMP as a substitute for TCP/WS what have you.

I think the most useful addition would be fully developing case 1) above. The java server has an embedded activemq which creates topics on demand. So it should be possible to make it work, then add a module that collects them all as they come in and updates the signalk-server.

So the result is that sending MQTT packets with just a value to a pedictable topic name will update the signalk-server. Really nice for the minimal-sensor approach, and the technique is probably applicable to other transports too

[rob42]

In fact its given me a crazy idea that the http://activemq.apache.org activemq server could replace the data-model at the heart of the java implementation! Since subscriptions, store and forward, filtering, multiple protocols, peer and hierarchical networks of activemqs, and sophisticated security are all in there already, it might be easier to use that then build it explicitly!

[pod909]

I've been working though some practical examples and I'm not sure sending just the value for a topic is gooding to work in anything but the simplest situations. As soon as there are multiple sources for a value you run into trouble.

[toqduj]

In addition, you cannot send timestamps along with a value, which can be quite valuable (ha) in some cases.

B.

On Sat, Nov 12, 2016 at 7:30 AM, pod909 notifications@github.com wrote:

I've been working though some practical examples and I'm not sure sending just the value for a topic is gooding to work in anything but the simplest situations. As soon as there are multiple sources for a value you run into trouble.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SignalK/specification/issues/291#issuecomment-260105265, or mute the thread https://github.com/notifications/unsubscribe-auth/AFMoyVZJFjcyP5-3jozlM5rkyWP9tCmGks5q9V0bgaJpZM4KtV6- .

[toqduj]

Other than that, I think it's a good idea to develop and see how it runs.

On Sat, Nov 12, 2016 at 8:46 AM, Brian P brianpauw@gmail.com wrote:

In addition, you cannot send timestamps along with a value, which can be quite valuable (ha) in some cases.

B.

On Sat, Nov 12, 2016 at 7:30 AM, pod909 notifications@github.com wrote:

I've been working though some practical examples and I'm not sure sending just the value for a topic is gooding to work in anything but the simplest situations. As soon as there are multiple sources for a value you run into trouble.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SignalK/specification/issues/291#issuecomment-260105265, or mute the thread https://github.com/notifications/unsubscribe-auth/AFMoyVZJFjcyP5-3jozlM5rkyWP9tCmGks5q9V0bgaJpZM4KtV6- .

[tkurki]

As soon as there are multiple sources for a value you run into trouble.

How so? MQTT Connect packet must contain a client identifier that can be used as the identifier for the source.

http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718031 https://github.com/mqttjs/MQTT.js#client

[pod909]

That would require every client to have unique credentials. How would that work in a zero config environment?

On Nov 12, 2016 09:47, "Teppo Kurki" notifications@github.com wrote:

As soon as there are multiple sources for a value you run into trouble.

How so? MQTT Connect packet must contain a client identifier that can be used as the identifier for the source.

http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1. 1-os.html#_Toc398718031 https://github.com/mqttjs/MQTT.js#client

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SignalK/specification/issues/291#issuecomment-260112514, or mute the thread https://github.com/notifications/unsubscribe-auth/AF0KF4xBXAq-8rJ2qwgd74_Opw9wiQD-ks5q9YtHgaJpZM4KtV6- .

[tkurki]

Did you read the spec and the defaults for mqttjs?

Every MQTT client already MUST have a unique client id per MQTT spec. This is distinct from authentication credentials, which btw are part of the MQTT spec as well.

Having a persistent client id is however a problem - if no clientid is specified mqttjs (used here as an example mqtt client lib) creates a random clientid for every connection.

But this is just something that should be specified in the MQTT-to-SK gateway spec, like "a MQTT to Signal K gateway client MUST provide a persistent client identification . The identification SHOULD follow the format ". So persistence is a MUST in addition to what MQTT spec already specifies.

Where did the zero config requirement come from? There is yet no way for the MQTT client to discover the server, is there?

[pod909]

I've read it, but clearly not thoroughly enough! :)

Comes with the territory when you start talking about low function sensors. You really just want to plug them into the network and that's it. When a sensor acts as a server, provided it's discoverable, everything is pretty straight forward. Gets more complicated when it has to find and send to something else.

Something like an mDNS service along the lines of _singalk_mqttbroker._tcp?

@rob42 I've installed activeMQ. Very straight forward.

[rob42]

Ive been investigating using a LastValue Cache queue, which would potentially hold value, timestamp,$source,identified by a message header . Seem workable but of topic for this thread,

[rob42]

@toqdoj The MQTT msg has a timestamp header I think, and there is no reason the payload could not be a json string with value, timestamp, Source. So the simplest sensor just sends a value to a queue, a smarter sensor sends a json snippet,

[rob42]

Actually it also works for REST PUT and POST....

[toqduj]

quoting @rob42

@toqdoj The MQTT msg has a timestamp header I think, and there is no reason the payload could not be a json string with value, timestamp, Source. So the simplest sensor just sends a value to a queue, a smarter sensor sends a json snippet,

I agree fully with this plan :).

On Sat, Nov 12, 2016 at 9:28 PM, rob42 notifications@github.com wrote:

Actually it also works for REST PUT and POST....

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SignalK/specification/issues/291#issuecomment-260146349, or mute the thread https://github.com/notifications/unsubscribe-auth/AFMoySOkij7B3k-C71PTLrA4E0V63uMlks5q9iF9gaJpZM4KtV6- .

[pod909]

Been doing some work today on this approach and bringing the format of the delta and way values are represented in signal K object together. There are some differences that are worth ironing out at this point.

On Nov 12, 2016 20:32, "Brian R. Pauw" notifications@github.com wrote:

quoting @rob42

@toqdoj The MQTT msg has a timestamp header I think, and there is no reason the payload could not be a json string with value, timestamp, Source. So the simplest sensor just sends a value to a queue, a smarter sensor sends a json snippet,

I agree fully with this plan :).

On Sat, Nov 12, 2016 at 9:28 PM, rob42 notifications@github.com wrote:

Actually it also works for REST PUT and POST....

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SignalK/specification/issues/291# issuecomment-260146349, or mute the thread https://github.com/notifications/unsubscribe-auth/AFMoySOkij7B3k- C71PTLrA4E0V63uMlks5q9iF9gaJpZM4KtV6- .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SignalK/specification/issues/291#issuecomment-260146573, or mute the thread https://github.com/notifications/unsubscribe-auth/AF0KF9e-nJrwcjOASQ19SkzMFLnMa-8gks5q9iJYgaJpZM4KtV6- .

[tkurki]

There is no time related header in MQTT PUBLISH message, nor the other messages.

[rob42]

@tkurki Yes you are right. So for a value the serer would add time received, or sensor must send json snippet

[pod909]

I think, always a json. Sometimes an object with just a "value". Should be consistent across transports and with how a value is represented in the main sk object (so the server can just copy/merge the content into the tree).

On Nov 13, 2016 00:33, "rob42" notifications@github.com wrote:

@tkurki https://github.com/tkurki Yes you are right. So for a value the serer would add time received, or sensor must send json snippet

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SignalK/specification/issues/291#issuecomment-260158220, or mute the thread https://github.com/notifications/unsubscribe-auth/AF0KF3q9aeR7iu-o9JSksE1RcUZmixdlks5q9lq8gaJpZM4KtV6- .

[tkurki]

I think, always a json. Sometimes an object with just a "value".

@pod909 I think the whole point of use case (1) "MQTT enabled sensor" is how a non-SK sensor with just MQTT capability could send data to SK data model. The mapping between SK data model and topic structure is clear and logical for plain values - why would you want to specify "only JSON allowed"? You are forcing the burden of generating SK-sanctioned messages to the sensor, which is not necessary, and basically saying that use case (1) is not viable - a sensor MUST talk Signal K over MQTT.

Should be consistent across transports

If you require that messages are always JSON then why not just specify that they must be deltas, standard topic is /signalk and close this issue - what more is there to document? Why would the message be something else than current delta?

[toqduj]

So the minimum message that can be sent would then be:

{"value": 3.141592652589}

I think that should be doable for any sensor, no matter how dumb...

B.

On Sun, Nov 13, 2016 at 6:23 AM, pod909 notifications@github.com wrote:

I think, always a json. Sometimes an object with just a "value". Should be consistent across transports and with how a value is represented in the main sk object (so the server can just copy/merge the content into the tree).

On Nov 13, 2016 00:33, "rob42" notifications@github.com wrote:

@tkurki https://github.com/tkurki Yes you are right. So for a value the serer would add time received, or sensor must send json snippet

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SignalK/specification/issues/291# issuecomment-260158220, or mute the thread https://github.com/notifications/unsubscribe-auth/AF0KF3q9aeR7iu- o9JSksE1RcUZmixdlks5q9lq8gaJpZM4KtV6- .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SignalK/specification/issues/291#issuecomment-260167870, or mute the thread https://github.com/notifications/unsubscribe-auth/AFMoyeIb6S_0Qw462wSbroNCUH4GoICPks5q9p7DgaJpZM4KtV6- .

[tkurki]

I think there is at least one more relevant use case:

(4) MQTT enabled client and Signal K to MQTT gateway. For example a simple display that can connect to MQTT broker and receive data. The idea is that the client knows nothing about Signal K, only MQTT. This is basically the same thing as (1), only in reverse: the Signal K to MQTT gateway publishes all incoming data in relevant topics and the client can subscribe to any value it wants. For example a display could subscribe to data in topic /vessels/self/environment/outside/temperature (or /vessels/self/environment/outside/temperature/celsius) and receive plain values.

[tkurki]

How is {"value": 3.141592652589} better than 3.141592652589?

[toqduj]

That was based on the suggested minimum JSON requirement. I'm trying to think what the absolute minimum SK-valid delta message would look like, Something along these lines as shown below based on the example on the SK site, although as discussed above, "context" might be added by the receiver when it arrives in the appropriate MQTT topic. That still means the topic will be coded into the sensor program, so it's there somewhere.. Anyway, minimum SK delta still is pretty big.

{ "context": "vessels.230099999.environment.outside.pressure", "updates": [ { "source": { "$source": "dumb.sensor" }, "values": [ { "value": 43374 } ] } ] }

On Sun, Nov 13, 2016 at 8:36 AM, Teppo Kurki notifications@github.com wrote:

How is {"value": 3.141592652589} better than 3.141592652589?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SignalK/specification/issues/291#issuecomment-260171538, or mute the thread https://github.com/notifications/unsubscribe-auth/AFMoyQdGgfuOan9MkheUgYgKM_puouWBks5q9r4CgaJpZM4KtV6- .

[tkurki]

Rewinding back to the beginning of this discussion (or actually before that, when @toqduj started the work on his sensor node): how much more straightforward would it have been if you could have started just pushing number values as strings to /vessels/self/navigation/speedOverGround than to figure out what kind of JSON you need to produce and where it should go?

[jboynes]

@tkurki I like the idea of just pushing values but that still leaves the problem on configuring which topic to send to. I tried to cover that in #288 but that relies on the rather verbose delta format.

An alternative would be send values to a topic like /acme.THM-1.12345/temperature where acme.THM-1.12345 is unique to that sensor and then have the aggregator map to the appropriate SK key.

[tkurki]

The minimum bootstrap information that a generic MQTT sensor needs is

• broker address (host + port)
• topic to push to

Can't get around configuring those, but given that they are configured we should be able work with that. No extra Signal K knowledge needed in the sensor.

[toqduj]

@tkurki Pushing single values to a topic would have been easier, as I don't need to construct JSON. However, the GPS fix comes with a GPS fix timestamp (which is up to several seconds old in the worst case) that should be sent along with the data. This is only possible if put in a JSON.

For many other values and sensors, however, like a MHU or an environmental sensor bank, just pushing single values to an MQTT topic would be much preferred, as constructing a JSON message in that case would not bring anything extra.

On Sun, Nov 13, 2016 at 8:55 AM, Jeremy Boynes notifications@github.com wrote:

@tkurki https://github.com/tkurki I like the idea of just pushing values but that still leaves the problem on configuring which topic to send to. I tried to cover that in #288 https://github.com/SignalK/specification/issues/288 but that relies on the rather verbose delta format.

An alternative would be send values to a topic like /acme.THM-1.12345/temperature where acme.THM-1.12345 is unique to that sensor and then have the aggregator map to the appropriate SK key.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SignalK/specification/issues/291#issuecomment-260172117, or mute the thread https://github.com/notifications/unsubscribe-auth/AFMoyY2atiof68v_AyUm-snmDmv1LDzrks5q9sKEgaJpZM4KtV6- .