wutu / pimatic-mqtt

MQTT plugin for Pimatic
https://pimatic.org/plugins/pimatic-mqtt/
GNU Affero General Public License v3.0
9 stars 13 forks source link

parsing json depends on name attribute that is used in GUI #26

Open pascalsaul opened 6 years ago

pascalsaul commented 6 years ago

I'm trying to use data from Sonoff flashed with Tasmota over MQTT. To parse the JSON, the name attribute is used, to parse it correctly I need to add a dot (.) to the name. This conflicts - I guess - with the Pimatic convention, resulting in an unusable variable for rules.

image

This parses the following message from MQTT:

tele/th01/SENSOR {"Time":"2017-07-16T20:06:46", "DS18B20":{"Temperature":22.7}, "TempUnit":"C"}

I think the name attribute should be seperate from the parsing logic / attribute. This way you can add whatever you want to the parser, and still use a correct name for pimatic Pimatic.

wutu commented 6 years ago

For JSON payload I use flat (https://www.npmjs.com/package/flat) and it has a teat annotation. I'll look into it in the future.

rspaargaren commented 6 years ago

I am having also some trouble related to this. I want to use multiple attribute to the MQTT device however each topic contains a JSON string with almost the same setup: {"name": "temp", "type": "float", "value": 35.43, "timestamp": 1506877054152} so I have to name the attrib: value and this can not be repeated with the same name.

wutu commented 6 years ago

Hi @rspaargaren. Do you want to read data from multiple devices into one MqttSensor?

rspaargaren commented 6 years ago

I have got an OTGW which sends out MQTT messages. Unfortunately not very efficient so for every value I receive a message. So for example I want to create a sensor with multiple values:

events/central_heating/otmonitor/boilerwatertemperature (topic)
{"name": "temp", "type": "float", "value": 72.08, "timestamp": 1506888918369} (message)
events/central_heating/otmonitor/returnwatertemperature (topic)
{"name": "temp", "type": "float", "value": 63.00, "timestamp": 1506888947406} (message)

I can only add them if I call the attribute "value" but if I do this for both of them it does not work. To avoid this maybe you can add a unique attributeid instead of using the name of the attribute to identify? That would resolve @pascalsaul problem as well?

wutu commented 6 years ago

@rspaargaren But if I use the attributeid it will still be "value" for both topics. In this case, I would have to identify which topic the msg came from. Because the topic is used to identify the value in your case.

So, use two MqttSensors device in Pimatic or specify unambiguously value in payload for now.

In any case, I will be doing this quite massively reworking. Using the router for msg should be solved.

rspaargaren commented 6 years ago

looking forward to see your updated plugin. So far I like it and use it more often in Pimatic. If I run through your code for the sensor. After receiveing a mqtt message, you are running through the attributes, after having a match on the Topic of your attribute you are "decoding" the message. Than you are comparing the name. If you have a match again you set the value based on name and number. This will give conflict if you have two equal names as you don't know which to update...? So can't you make a seperate identifier (id) to know which parameter to update after having a match on topic and name?

sandervandegeijn commented 6 years ago

Also having this problem: you can add multiple sensors to 1 entry. This is possible because multiple topics are allowed for 1 sensor. The problem is that it tries to get the json attribute by using the name of the attribute, if you have multiple sonoffs that you want to add to 1 sensor the name is the same for each device and will generate a conflict.

I see two solutions:

  1. Only one topic for one mqtt-sensor, attributes are really attributes then for that topic
  2. Don't try to parse the json based on the name of the attribute, but on a new property that contains the key from the key/value pair in the json message.

I prefer option 2.