FlyingDiver wrote:
MQTT Connector Error Algemeen - MQTT Broker: Disconnected with result code 1
cuhouse wrote:I have updated to MQTT Connector (0.0.12) and MQTT (0.0.4) MQTT Shims. All updated fine.
I hoped the update might clear up an issue that I just noticed the end of this week. I do not see the state indicator change in the Indigo Home window for the device. I guess I never noticed it before now since that line in always highlighted when the On/Off is initiated.
Thanks again for all your time spent creating these plugins.
Jody
cuhouse wrote:I updated to the Plugin Store latest release for both of your MQTT plugins and the ON/OFF Indigo Status now changes to green when the device is ON. Thanks!
The other non power icons i.e. thermometer, humidity (the ones I have) remain in a constant grayed out state.
cuhouse wrote:1.) I run two MQTT servers. ActiveMQ on the local machine and a free cloud MQTT server (CloudMQTT). Several times I have noticed that the CloudMQTT broker will error out to Disconnected 1 vice Connected 0. I know the CloudMQTT broker is still online as I can publish/control and device via MQTT Explorer. A reload of the MQTT Connector plugin always resolves the issue. It happened again this evening when I was doing an update on my Ubiquiti network equipment that disconnected the house from the internet. I reloaded the Connector plugin to clear the Disconnect 1 error on the CloudMQTT broker. To confirm that a break in the internet path is what is causing it, I disconnected the ethernet connection to the Mac Mini hosting Indigo and that caused the Disconnect 1 error. Is there some automation that could be put in place to reset the broker connection in the plugin for cases like this?
cuhouse wrote:
2.) This really a minor thing but I am still running MQTT Gateway and notice this difference. On a device where I am controlling a relay just as an example, the MQTT Gateway plugin relay change and the ON/OFF status change simultaneously. On the same device with MQTT Shim the ON/OFF status change lags behind the actual relay change like a second or two. Maybe this is due to the queuing and cannot be changed? Like I said not a big deal just something I noticed since I am also running the other plugin. I did change to using RESULT for the status as you noted early on and did not change this delay.
FlyingDiver wrote:I don't notice anywhere near that much delay. You need to make sure your subscriptions and triggers don't queue up any more messages than are actually needed for the shim devices. If you have a lot of MQTT traffic, and you send all of it through the queuing mechanism, you could get significant delays.
For example, one of the systems I'm currently integrating is an raspberryPi running Home Assistant with a couple sensors attached. It's connected to the Internet using a Verizon hotspot. When one of the sensors changes, it sends an MQTT message to a cloud server (Digital Ocean droplet) running a Mosquitto broker. My production Indigo system is connected to that MQTT Broker, and I have Shim devices for the sensors attached to the remote rPi. When I trip one of those sensors, I see the change reflected in Indigo in less than a second.
glitz wrote:Is there a way that I can retrieve the list if published devices from the plugin?
I want to use it (for security reasons) in a python script, to check if each device is among the published ones before I update the status based on MQTT messages.
device = indigo.devices[214852033]
indigo.server.log(u"{}: Published devices:".format(device.name))
for dev in device.ownerProps['published_devices']:
indigo.server.log(u"{}: {}".format(device.name, dev))
Is this script internal or external to Indigo?
Are you planning to exclude published devices from updating?
FlyingDiver wrote:MQTT Connector release 0.1.3 - automatically reconnects if broker connection is lost.
Users browsing this forum: No registered users and 6 guests