I was referring to the vera-mqtt client publishing data to a broker. Are you using this version of the plugin on Github?
Ah, ok - āsubscriptionā was added to a fork after my involvement and I only publish data from the Vera. If you describe your use case, perhaps we can find a solution that works within the subscription limitations of the current plugin.
alright.
So,
it is possible to create a virtual device, and add it as a child of the mqtt device. that will create 2 fields in the variables inside the child device.
mqttTopic and mqttTarget.
now it is fully supported to add
āurn:micasaverde-com:serviceId:HumiditySensor1,CurrentLevel=payload.moistureā inside the mqttTarget field to get the value of the moisture level, but right now there is no support to add multiple lines to get more values from the json data.
I believe the plugin can not do what you want in itās current form so Iām still trying to understand your use case at a higher level because there maybe a simple way to accomplish your overall goal if we augment the plugin capabilities with something else to close the gaps. For example, some custom LUA code, an external mqtt message processor like node red or perhaps Reactor.
yes, i hope there is some workaround. I have Reactor installed but not used yet.
@mapa, can you describe your broader goal? Why do you need both values/variables in a single child subscriber device vs. two as the plugin suggests? What is it that you are trying to do/accomplish?
my goal is to have as much data in as few devices as possible. If the data is associated somehow, then it seems logical to have it as close together as possible. In this case, my overall goal would be to have a custom device which would show all data that i get in the json. but having one value and batterylevel would initially be ok.
Thanks. How are you publishing the miflora data to mqtt?
Im using GitHub - ThomDietrich/miflora-mqtt-daemon: Linux service to collect and transfer Xiaomi Mi Flora plant sensor data via MQTT to your smart home system, with cluster support š±š¼š„š”š³ together with Eclipse Mosquitto Broker
Looks cool. So the data goes from Miflora(BLE)->Miflora-mqtt-daemon->mosquitto->vera-mqtt so therein lies the opportunity. Not sure what you are running your miflora-mqtt-daemon on, but one option is to also run nodered to organize the miflora measurements into a payload more convenient for the vera-mqtt plugin to display the combined data on a single virtual device. It would look something like this Miflora(BLE)->Miflora-mqtt-daemon->mosquitto->nodered->mosquitto->vera-mqtt. Using nodered, you would configure it to consume miflora messages from mosquitto, tidy up the json they way you would like and republish it to mosquitto using a topic that the vera-mqtt client subscribes to. I also noticed that there is a miflora node available for nodered so you could use nodered to collect the miflora measurements directly so you wouldnāt need to run miflora-mqtt-daemon at all.
The reason that I only publish data from the vera using vera-mqtt is because I have a nodered instance subscribed to the vera mqtt messages that streams the measurements to an influxdb instance for visual analysis using Grafana. Sounds complicated but it is actually very simple because nodered is so flexible. It would be a great way to view your miflora measurements unless your goal is to use the miflora measurements as triggers on the Vera.
sound good. I am actually familiar with influxdb, grafana and telegraf but for server utilization observation. But it might be a way to go to visualize, as you say. I will definately look into the miflora-nodered tonight. might be a better solution. though the main problem to solve would be how to structure the data to somehow make it better for vera-mqtt.
Hi Blacey, i solved it using your idea. miflora-mqtt->node red-> http request to vera. i think it was the quickest way, as my programming skills are somewhat limited :-).
// Marcus
1 Like
Hi Marcus, excellent and congrats! Also, I havenāt personally used it but there is also a NodeRed Vera/MIOS node available and NodeRed users active on the Vera forums here. If you so desire, it looks like you can replace the http request with the MIOS/Vera Node node.
Thanks a bunch. I will totally look into that.
Hi @vosmont and others. Iāve had the SensorMqtt plugin (vosmontās version 0.3) for a good while on VeraPlus and it works great. Now Iām trying to get it to work on openLuup and Iām running into a problem.
Iām not a lua person so I donāt really understand this error. Iām running openLuup on a fairly minimal Alpine Linux 3.7 and itās possible Iām just missing a dependency. But I donāt know how to figure that out.
root@alpine-openluup-766746687c-b22j9:/etc/cmh-ludl# tail -F logs/LuaUPnP.log|grep -i mqtt
tail: logs/LuaUPnP.log has been replaced; following end of new file
2019-10-01 16:28:26.082 openLuup.scheduler:: [33] MQTT Client device startup
2019-10-01 16:28:26.083 luup_log:33: SensorMqtt: Loading plugin module L_SensorMqtt1 ā¦
2019-10-01 16:28:26.097 luup_log:33: SensorMqtt: Plugin module L_SensorMqtt1 loaded
2019-10-01 16:28:26.097 luup_log:33: SensorMqtt: Initializing SensorMqtt
2019-10-01 16:28:26.101 luup.variable_set:: 33.urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1.mqttServerConnected was: 0 now: 0 #hooks:0
2019-10-01 16:28:26.102 luup_log:33: SensorMqtt: Connecting as MQTT client: Vera-88800000 to mqttServerIp: $$$.cloudmqtt.com mqttServerPort: 1$$$ā¦
2019-10-01 16:28:26.102 luup_log:33: SensorMqtt: Authenticating with username: Vera$$$$$
2019-10-01 16:28:26.102 openLuup.context_switch:: ERROR: /usr/share/lua/5.1/mqtt_library.lua:244: attempt to index global āsocketā (a nil value)
2019-10-01 16:28:26.102 openLuup.scheduler:: job aborted : /usr/share/lua/5.1/mqtt_library.lua:244: attempt to index global āsocketā (a nil value)
My only guess is that something should be providing the global āsocketā object. This is the line of code that tanks:
self.socket_client = socket.connect(self.hostname, self.port)
Iāve installed lua5.1 lua-socket lua-filesystem lua-sec but like i said I might need more. The rest of openLuup is working fine.
Thanks!
In the early part of /usr/share/lua/5.1/mqtt_library.lua Iāll bet you find this:
if (not isPsp()) then
require("socket")
require("io")
require("ltn12")
--require("ssl")
end
Some versions of Lua will define a global with the name of the loaded module when using require, and some do not. Lua on my Veras does, but on my Ubuntu VM that I regularly use for development (and openLuup) it does not. To fix:
if (not isPsp()) then
socket = require("socket")
io = require("io")
ltn12 = require("ltn12")
--ssl = require("ssl")
end
(I put the fix in the comment even though it wonāt be used, just for consistency)
Yes, and thanks for that. After banging on this for a few more hours I had concluded similarly that the āif not Pspā block wasnāt setting a global collection, therefore there was no global. What is Psp anyway?
But thatās interesting that some luas will push require to a global and some not.
I got socket and therefore the connection to work, but after a bit there is a new error. So onto the next puzzle I guess.
ERROR: files/L_SensorMqtt1.lua:331: attempt to index upvalue āaliasā (a boolean value)
2019-10-01 19:26:28.248 luup_log:33: SensorMqtt: Watch event - device: 10320 variable: ArmedTripped value 0 => 1
2019-10-01 19:26:28.248 openLuup.context_switch:: ERROR: files/L_SensorMqtt1.lua:331: attempt to index upvalue 'alias' (a boolean value)
2019-10-01 19:26:28.248 openLuup.scheduler:: 10320.urn:micasaverde-com:serviceId:SecuritySensor1.ArmedTripped ERROR files/L_SensorMqtt1.lua:331: attempt to index upvalue 'alias' (a boolean value) function: 0x882820
2019-10-01 19:26:32.900 luup_log:33: SensorMqtt: Connection down: socket_client:receive(): closed
2019-10-01 19:26:32.901 luup_log:33: SensorMqtt: MQTT connection status changed from "Connected" to "Disconnected"
2019-10-01 19:26:32.901 luup.variable_set:: 33.urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1.mqttServerStatus was: Connected now: Disconnected #hooks:0
2019-10-01 19:26:32.901 luup.variable_set:: 33.urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1.mqttServerConnected was: 1 now: 0 #hooks:0
2019-10-01 19:26:38.071 luup_log:33: SensorMqtt: Connection down: /usr/share/lua/5.1/mqtt_library.lua:382: MQTT.client:handler(): Not connected
2019-10-01 19:26:43.109 luup_log:33: SensorMqtt: Connection down: /usr/share/lua/5.1/mqtt_library.lua:382: MQTT.client:handler(): Not connected
Everything working great now.
Hmm The subscribe functionality of this plugin could be used to get data from Zwave2MQTT as it is still work in progress, I am considering to create a device bridge from openLuup to an instance of Zwave2Mqtt so as to replace the vera with a much more open and reliable alternative with that project turns out to work well and indeed better than where the vera is currently going.