Suggestion on basic JSON design for devices and best practice

Setup, Configuration and Use Beginners
1

Hi all,
I am new to this community and designing my own devices which is capable to connect to openhab with MQTT. I searched through the forum and most of the solutions are code based whereas I do not wish to involved at this point. So I currently simply interact with Paper UI.

Because I wonder if my existing Json format is system friendly. For example,
config.json:

{
    "config": {
        "type": "devicetype",
        "name": "home/room/device",
        "wifi": [
            {
                "id": "wifi1id",
                "pw": "wifi1pw"
            },
            {
                "id": "wifi2id",
                "pw": "wifi2pw"
            }
        ],
        "ota": {
            "host": "otahost",
            "port": otaport,
            "id": "otaid",
            "pw": "otapw"
        },
        "mqtt": {
            "host": "brokerip",
            "port": 1883,
            "id": "mqttid",
            "pw": "mqttpw",
            "topic": "discoverytopic"
        }
    }
}

params.json:

{
    "params": {
        "smart": {
            "on": 0,
            "delay": 60,
            "sonic": {
            "on": 170,
            "spl": 3
            },
            "rt": {
                "on": 300,
                "spl": 3
            },
            "pir": {
                "spl": 100
            }
        },
        "on": 1
    }
}

status.json:

{
    "status": {
        "on": "ON",
        "sonic": 100,
        "rt": 25.5,
        "pir": 100,
        "delay": 60000
    }
}

The device should transmit its status.json periodically.
Params.json should be different per device and be able to update remotely.
Config.json is preset and normally does not change.
Every device subscribes to its own topic “home/room/function” and can be discovered in “discoverytopic” topic.

With currently setting, their status can be shown in openhab with, for example, “On/Off switch” channel setting: MQTT state topic: “home/room/device” and Incoming value tranformation “JSONPATH:$.status.on”.

To change the parameters, the Things, for example, could be a “number value” Channel with settings MQTT command topic: “home/room/device” and Outgoing value format: {“params”:{“on”:%s}}

Not sure if this is the right way to do because, previously, I wish to transmit an updated params.json per request so as to update values in “Control” page but it failed due to restricted size of mqtt packet. So I am not sure how to retrieve and show the params.json in openhab. One way might be transmitting all parameters one by one peroidically but this would cause heavy load to bandwidth with redundancy data.

Is it common to keep the json in single level so there is no need to enter the “Incoming value tranformation” and “Outgoing value format” when creating a channel?

Does MQTT embedded broker supports wildcards? this possibly helps to eliminate the discovery topic.

appreciate for any suggestion.

2

Most friendly would be if you implemented your devices to follow the Homie convention. https://homieiot.github.io/

The MQTT 2.x binding can automatically discover devices who follow this convention. And this would largely replace your JSON structure with separate topics.

As for your specific JSON, the JSONPATH binding doesn’t handle arrays all that well. So those might cause some problems.

If these are JSON messages you want to publish, realize that OH doesn’t have great support for building JSON strings so you will have to build this using String manipulation which is pretty ugly.

Typically MQTT is used in this space with one topic per piece of data instead of using a complicated message encoding like JSON or XML. Encoding the data like this mainly serves to create messages that are larger than necessary, require more processing, and require taking up limited space on microcontrollers to include libraries to parse them. But if you use your MQTT topic structures for lots of this sort of data instead of encoding then you can avoid all that overhead.

Remember, MQTT was designed to be used with devices with very constrained resources and unreliable networks.

So why not just report it on demand. That’s how Shelly and I think Tasmota does it. Have a well know topic that you can send a message to. As a result the devices will publish their paramers info.

Ultimately, the resources required to periodically publish this data is far less important than the resources required for the microcontroller to build up and send a large JSON formatted String or to parse a JSON formatted String.

If it’s JSON you will be required to use those or the JSONPATH transform. It doesn’t matter how many levels it has.

I think the answer is yes but it would be more correct to create the discovery topic, or even better, look at what Homie does in this regard.

3

Thanks for the reply.

spent some time reading the homie and research on how the openhab should look like.

I am getting started to config openhab with text files and saw how complicated if all parameters are shown in sitemap. I realized, at the end of day, the smart parameters will not be relevant to show. I would supervise those parameters via python instead.

Homie looks popular in MQTT platform and the broadcast channel looks useful, though I would like to control my office and home which end up the root of topic “homie” might not be enough or I have to split the string in middle level to retrieve the location of the message. Not sure if the following still satisfy Homie requirements:
home/kitchen/vent and home/1stfloor/bedroom/aircon
office/reception/lighting and office/20thfloor/rm1234/lighting

importantly, In order to properly well-organize the list of the devices, I wish to combine the auto switch and manual switch as a multistate switch such that the device would report
0: MANUAL OFF
25: AUTO OFF
75: AUTO ON
100: MANUAL ON
and command would be
0: MANUAL OFF
1-99: AUTO ON
100: MANUAL ON
I’m not sure if openhab offers some fancy control layout for sitemap or UI to support that like SwitchItem? maybe color LED?

4

You could use a Dimmer Item and a slider, setpoint, mappings, or selection element.

Typically, the location of the device is modeled in openHAB, not in the devices themselves. This is usually because the vendors don’t know where you are going to place your device. So I doubt the Homie standard would support topics like that, but I don’t know that for sure.