david@berto.co.uk

Are you using the Sonoff Zigbee Bridge or Zigbee2MQTT? I have it working on both setups. If Tasmota then what version are you running? Thanks

The hub exposes Control4 devices that you set in the driver to Homebridge not the other way round. Sorry

What are the powerboards you’re using? I assume they are running Tasmota, you’re just using Tuya to flash the devices? What module are they configured as? The hub is used as the mqtt broker for all devices and the IoT Gateway. The assist pin code is used for Google Assistant integration and does not use the hub at all.

The VM needs to be accessible using SSH and the user needs to have sudo access without the need for its password. Alternatively your can find the install script on the main controller in /mnt/internal/c4z/Berto_IOTGateway/hub/install.sh.

You only need the hub if you a) Plan to use MQTT as the protocol for Shelly/Tasmota devices b) Want to integrate Flic buttons c) Want to use Zigbee2MQTT d) Use a RestFUL HTTP endpoint to have your own code interpret custom MQTT messages. You can create your own endpoint service, the hub install has an example setup. if you have lots of Shelly/Tasmota devices (30+) I would recommend MQTT as it very fast and provides instant real-time feedback. The Lifx, TP-Link, Yeelight and Sonoff DIY integration uses their own LAN protocols ie. does not require access to their o

Lots of options on devices but my recommended would be Shelly 2.5, https://shelly.cloud/products/shelly-25-smart-home-automation-relay/ €20, in relay mode. No need for MQTT broker if control and feedback is all from Control4. I use Control4 dual relay blind driver, works a treat.

A major updating adding support for many more devices including TP-LINK and Yeelight. Zigbee is now supported on the Sonoff Zigbee Bridge and Zigbee2MQTT installs. The new IoT Gateway driver supports automatic downloadable plugins which means new devices no longer need a driver update. As new devices become available the driver now checks it’s online database for a supported plugin and downloads as required. Custom MQTT messages can now be posted to a RestFUL API endpoint to process payloads and return name/value pairs to feedback variable updates to Control4. Process messages an

Confused as to what your referring to. I was just responding to the incorrect compliance comment, nothing more.

100% correct. Referring to the use of custom email services, which were subsequently moved into the cloud, and nothing to do with the incorrect comment reference C4 compliance.

Then web server driver was written/released a few months ago and has no connection to what you are referring to. Like I say, it is no more complicated than Ryan’s original HTTP driver.

What modifications has this driver had at the request of C4? The driver is based on Ryan’s driver, just goes further but I’m not aware of any modifications made to be more compliant? Thank you

My IoT Gateway provides Homekit/Siri integration along with Google Assistant and Alexa coming soon. It also allows integration of may other IoT devices. See https://berto.io/berto-iot-gateway and https://berto.io/how-it-work

The issue was that SetOption19 was on for auto discovery for a Home Assistant system which changes the published messages from the device for tele and stat reporting. Will have a look at making the Gateway work with the HA format also.

A Push should happen after a Discovery completes, what is the Tasmota module that is set on the device? The MQTT client does only restart when a Discovery is started but I could probably force a restart on the Custom Topic change, will take a look. I’ll check the event firing issue. Any issues can be emailed to support@berto.co.uk. Thanks David

So does the Alexa driver rely on the OpenVPN connection being up? Interesting post.