Indigo Domotics

OK, I did that in a hurry and obviously it's no good. I'll work on it tomorrow.

Try this one: https://github.com/FlyingDiver/Indigo-M ... /tag/0.1.2

I actually tested it.

FlyingDiver wrote:

Try this one: https://github.com/FlyingDiver/Indigo-M ... /tag/0.1.2

I actually tested it.

Perfect!

-Eric

Good to hear. I pushed this version to the plugin store.

Hi,

Using version v0.1.2 of the MQTT Connector I am getting the message below in the log :

Code: Select all

 MQTT Connector Error            Algemeen - MQTT Broker: Disconnected with result code 1

This only occurs when subscription is set to : /devices/#
When I set a device specific subscription this does not happen.


Regards,

Wouter

That's a broker error of some kind. Try subscribing to "devices/#" instead. Otherwise you need to check error logs on the broker.

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.

Screen Shot 2019-08-17 at 3.30.34 PM.png

Thanks again for all your time spent creating these plugins.

Jody

Joe,

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.

I have been using your MQTT plugins since pre release and all is VERY stable. I have encountered two items that have been small issues so far.

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?
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.

I will be adding some updates soon as I have been busy testing other devices with your plugin.

Still loving it!
Thanks,
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.

Yeah, I guess I should be using the "On" variant of those icons. I'll change that next release.

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?

That's a valid request. Can you open a GitHub issue for it? That's a non-trivial change so it needs to be tracked.

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.

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.

Thanks for the fast reply. I submitted an issue to GitHub.

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.

I will do some troubleshooting now that I know the delay is not normal.

Jody

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.

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.

Is this script internal or external to Indigo?

Are you planning to exclude published devices from updating?

Put in the DevID of the broker device.

Code: Select all

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?

It's internal and I'm gonna use it to exclude updates of devices that are not published. That is, if I receive a message from smartthings for a device that is not published, It shouldn't update that device in Indigo. Thanks for the code, exactly what I needed!

MQTT Connector release 0.1.3 - automatically reconnects if broker connection is lost.

FlyingDiver wrote:

MQTT Connector release 0.1.3 - automatically reconnects if broker connection is lost.

Joe,

Works great! No issues now when re-establishing the internet connection. Connections restart automatically..

Thanks,
Jody

P.S. Do you prefer we request additions to the MQTT plugins directly through GitHub or should we initiate them on the forum first?