david@berto.co.uk

On 11/20/2023 at 4:26 AM, RobP said:

also not sure if it's part of the same problem or not but I get this error when reloading or updating the driver action field

LUA_ERROR [id: 224][name: Berto Agent][file: Berto_Agent.c4z]: squish.lua:188: attempt to concatenate field 'c4z' (a nil value)
 

This is now fixed.

The latest beta 4.2 is a complete rewrite of my MQTT client from the ground up.

I've tested connecting to Mosquitto 2.0, unencrypted and over TLS, unauthenticated and using authentication, support over WebSockets and all levels of QOS.

You can test connections using https://test.mosquitto.org and https://www.hivemq.com or use your own broker.

Whilst the client can connect to the local controller broker I do not advocate this or any chnages to the local mosquitto configuration. A broker on a Pi takes less than 5 minutes to setup.

The v2 drivers are still in beta but I hope to release a production version soon, time permitting!!

Available at https://beta.berto.io/c4z

https://beta.berto.io/c4z/Berto_Agent.c4z

19 hours ago, Amr said:

Am trying to get this configured, I can't find or install Berto Agent?  Its not listed whatever I do? Any idea how to find it or install it?  I just dropped the files to drivers directory with old Berto files, do I need to remove old files first?  Also Berto_RelaySensor is named Berto_Unknown in the list.

All drivers are available are https://beta.beta.io/c4z

Still WIP but LIFX and Wiz should be ready soon with Color support. 

3 hours ago, OceanDad said:

Yeelight was locking up for me - unable to control intermittently if you used the color wheel for a bit.  Have just updated, so will see if this fixes things.

Yeelight has a rate limit on the requests sent to a bulb.

The Color wheel sends requests at a higher frequency than simple on/off and level commands.

I suspect the issue you are seeing is the quota restriction on the Yeelight bulb rather than the driver.

On 6/14/2022 at 10:57 AM, OzSoup said:

Cannot get the LIFX (v1.1) to work at all.  It doesn't even list a version under driver management info. (see attached)  Did you get it working Amr?

Berto Agent v1.0 is running under Agents and I tried the Yeelight bulb I have with the Yeelight Berto driver.  It detects and lists as v1.0.

This does not look as though the driver has installed correctly. I would delete from project and also /mnt/internal/c4z on the controller and then try again.

You should get the drivers from https://beta.berto.io/c4z and change the Release Branch to Beta under Core Configuration in the Berto Agent driver.

Thanks

2 minutes ago, TundraSonic said:

This is very intriguing. Any thoughts on how Berto compares to the new Chowmain driver?

When converting from Chowmain… Can the two coexist or do we need to kill the Chowmain driver?  I've a good bit of LIFX via Chowmain programmed in to scenes and apps so coexisting to give me time to slowly migrate over would be good.

Not sure ref Chowmain driver but think it should be ok to run along side as the Berto driver uses the LIFX LAN not the cloud API. 

I’ve just pushed a first release with Color support etc. Ready to test and available at https://beta.berto.io/c4z

On 5/20/2022 at 9:49 PM, Amr said:

So David, long time no hear, I hope u r doing fine, so v2 replaces v1? Also Cloud and Gateway drivers will remain or will be updated as well? To keep the ZB2MQTT we need to wait till you finish developemnt on v2, right?

Amr, 

v2 will replace v1, in fact I’ll probably make v2 OS 3.3.0 and above only given the great new features with native colour wheel support etc. I’m in the process of adding colour support now. The Mosquitto MQTT broker is bundled with OS 3.3.0 which is fantastic news and a native C4:MQTT() client to interface with. All brilliant additions.

The v1 drivers will still work but I’ve stopped development on them. The Cloud driver is replaced by Berto Agent which does all Cloud did and more. No need to register, no restrictions, support for Email, Pushover, MQTT, REST, IFTTT all built in and more.

The Gateway driver is being broken out into individual hub drivers eg. LIFX, Shelly, Tasmota, Yeelight, TP Link and Zigbee2MQTT is work in progress. I’ll probably create HA and HomeKit but leave GA and Alexa out, the C4 options are great now.

A lot to do and only me to do it unfortunately but I’ll keep you updated.

Cheers

David

Once OS 3.3 is released I'll add Color Wheel support to the Dimmer driver also.

I'm in the process of pushing a v2 release of my drivers which will eventually supersede all v1 drivers.

The new Agent driver now has many features bundled in that replaces previous v1 drivers such as IFTTT, Pushover, MQTT, Mail, REST/HTTP Webevents, OwnTracks...

See https://berto.io/v2

On 4/26/2022 at 3:01 PM, treynolen said:

I do this in my own home and I trigger the programming by the status of the alarm system (i.e... When Alarm armed Away -> monitor mode/auto answer on the tablets).   I don't have to do any sort of refresh and it happens pretty much immediately.  

What do you mean by "This automation works just fine in composer"?  It seems that it doesn't work if you are having to do something else manually, but I may be misunderstanding.  

 

My Berto Agent driver, https://prod.berto.io/c4z/Berto_Agent.c4z, provides the ability to programatically Refresh Navigators.

12 hours ago, Dueport said:

I don’t know about the Berto option. This could be interesting if the LIFX servers go down. What do you need to use the Berto LIFX driver? Do you have to run a raspberry pi to make it work?

The LIFX driver uses the LIFX LAN Protocol, https://lan.developer.lifx.com, so does not use the LIFX Cloud to manage the devices. You do not need Internet access for the driver to work.

You do not need any additional hardware such as a Pi for it work.

You need to install the Berto Agent driver first, https://prod.berto.io/c4z/Berto_Agent.c4z, and then you can install the Berto LIFX driver from the Feature Management property or download from https://prod.berto.io/c4z

Thanks

On 4/26/2022 at 5:40 PM, 416to305 said:

So, quick update, I removed the old Berto drivers and then added these new ones.  They worked and I could publish MQTT messages to my broker and all was well.  When I got up this morning though nothing would work any more, even logging into Composer and trying to publish a message the broker would never receive it.  If I use my other systems and publish messages the broker receives them right away, so it's only C4 that stops working.  I then reboot Director and immediately it starts working again.  It will be good for maybe 24 hours and then back to just doing nothing until I reboot Director.  Wish I had more luck with this but I can't keep it working for more than a day before it stops, so I will stick to the Generic TCP driver instead of MQTT as I have spent way too long already on this. Thanks!

The Agent driver will attempt to re-connect to the MQTT Broker if it misses a keep alive.

Update to Berto Agent Beta 1.3 should fix this issue. You need to have the Keepalive & Timeout set in the Broker configuration.

Have you written your own driver to use the MQTT client in the Agent?

On 4/21/2022 at 7:15 PM, 416to305 said:

Hi everyone, hopefully I can explain this properly but just wondering if this is something that can be done with C4 or if a driver has to be made for it.  I'll use MQTT as an example with the Berto IoT Gateway that I have set up today but this would apply to any driver like the HTTP webhook one that receives external commands.  With this, I can do things like subscribe to a topic like "zwave/kitchen_temperature" which can publish a message such as the temperature like "70" and so on.  I can then easily trigger events in C4, such as "if topic zwave/kitchen_temperature receives a message, do XYZ."

My question though is, can I use data from something like this but to actually update a C4 device? 

- Create a thermostat/temperature device in C4 like you would for any device

- Not bind it to any input sensor or temperature sensor

- Use the Berto MQTT driver subscribing to the zwave/kitchen_temperature topic

- Have Home Assistant every 5 minutes publish the current temperature in Fahrenheit to the zwave/kitchen_temperature topic

- Have C4 receive that message, and update the C4 Temperature sensor device to be the received temperature

So, almost like the Berto MQTT driver is the relay that receives the temperature and then updates it in C4.

I tried via programming but there's no actions that let you set the temperature sensor value, since it understandably wants to retrieve it from something connected to it.  I have tons of z-wave and other devices in Home Assistant that I can easily control from C4 via MQTT, but just wondering if there's a way to do the reverse and update devices in C4 based on MQTT, or if that is getting into custom driver territory.  Thanks!

1 hour ago, slip.cougan said:

I've also downloaded the chowmein sky q driver from driver central.

It attempts to connect, states that its online in properties but never pulls in the mac address. Logs show it constantly connecting>online>disconnecting.

Starting to think it's an issue with the Sky Q box as I've never seen this sort of thing happening before.

Despite stating its online, I never have control of the box.

The Sky Q boxes will not respond to ICMP requests.

You can try an nmap and see what open ports there are, it should something like :-

Host is up (0.0030s latency).
Not shown: 983 filtered ports
PORT      STATE  SERVICE
80/tcp    open   http
1234/tcp  open   hotline
5000/tcp  open   upnp
5001/tcp  closed commplex-link
6000/tcp  closed X11
6100/tcp  closed synchronet-db
8008/tcp  open   http
8080/tcp  open   http-proxy
8081/tcp  closed blackice-icecap
9080/tcp  open   glrpc
9091/tcp  open   xmltec-xmlmail
9998/tcp  closed distinct32
9999/tcp  closed abyss
49153/tcp open   unknown
49155/tcp open   unknown
49160/tcp open   unknown
49163/tcp closed unknown

You can wget or curl the Sky Q box direct, in your case :-

curl http://192.168.0.201:9006/as/system/information

This should return your info on the Sky box, if not then you have a network issue.

4 hours ago, Pncik said:

I use HA and have just started test Control4.

What is the ‘dodgy’ integration? Only thing I have found is simple HTTP access to Control4 system which I see uses standard C4 server sockets, how and why would Control4 shut this down?

Thanks help.

PM me you email and I’ll send you SDK details. 
 

v2 is still beta but the area your looking to develop in, MQTT, is complete. 

Mitsubishi uses it’s own M-NET bus protocol.

CoolMasterNet connects onto the same bus, see http://www.coolmasternet.co.uk/CoolMasterNet.html

The drivers are in the Control4 databases, https://drivers.control4.com/solr/drivers/browse?&fq=manufacturer%3A"CoolAutomation"

Works a treat.

https://www.p5.hu/index.php/products/ethernet-modules/366-fnip-12io

59 minutes ago, South Africa C4 user said:

A good response posted by C4:

Postmortem

August 25th Snap One Control4 Cloud Services Outage

Yesterday we experienced a global outage due to an unsuccessful maintenance release. The maintenance was intended to be a non-impactful step forward in increasing the reliability of many Snap-One Control4 cloud-based services.

During the deployment, we quickly detected a disruption and began to identify and isolate the cause. As we approached full recovery, we recognized that recovery would be faster if we rolled back changes. This unplanned event was broad, and we’re genuinely sorry for the impact on you (our Partners and End-Customers).

You rely on our services in a variety of ways. Our #1 goal is to provide you with excellent services; we missed the mark. If you are a customer, please know your technology partner did not cause this outage.

We take all unplanned outages seriously and respond with high urgency:

1.       We are conducting a complete root cause analysis, including reviewing our processes, practices, and technology efforts during this maintenance. We have identified a new approach and timings to minimize overall risk.

2.       We’ll evaluate ways to improve our remediation speed. We have an upcoming release that will speed controller reconnection to Snap One cloud services.

We have been and will continue to innovate and invest in fundamental improvements to the reliability of our cloud-dependent products. I apologize to you and sincerely thank you for your support. Feel free to email me for more information and to provide feedback.

 Alex Mann

Snap One Vice-President of Engineering -  Cloud Software, Data Science, & Cybersecurity

Agreed. An honest and professional response, a step in the right direction. 
 

Unfortunately for a NASDAQ listed company this particular service is not good and regular outages are far to common. 
 

Maybe is the US, and other parts of the world, remote cloud services are good but in the UK they are unreliable and are the brunt of complaints. 
 

We always sell 4Sight but for remote connectivity and performance it can not be relied up on here, VPN is the only reliable and secure alternative. 
 

Hopefully it will improve. 

20 hours ago, bphillips09 said:

I'm working on getting basic ISY>MQTT>Control4 set up using the MQTT driver and it's working great. All of my lighting is Insteon and I don't want to use the direct C4 integration as I like having the ISY for Insteon config, so it will be great to eventually have all my lights and switches set up using MQTT.

This would be great! I'm currently using ZWaveJS with Home Assistant so it would be great to get some native-type control over my ZWave devices like blinds and such that aren't supported by C4.

In the mean time I've released the source for some sample MQTT drivers that integrate via the Cloud driver to an MQTT broker of choice along with a Mail driver show SMTP integration.

You could write your own zwavejs2mqtt gateway...

Available at https://beta.berto.io/download/Berto_SDK.zip 

Thanks

2 hours ago, Amr said:

I belive fron the site directly, I don't think update had been pushed

2 hours ago, eon said:

I tried to force update the driver but its still on 1.12 where i can download fixed version?

PM me your email and I’ll send you the beta to test. 
 

Thanks

35 minutes ago, eon said:

It supports all kind of zwave devices and they are very fast, much faster than native zwave dongle of c4 with fibaro dimmer 2 and much faster than vera. At the moment on my zwave js network which i run with home assitant i have Fibaro Single Switch, fibaro Double Switch, Fibaro Dimmer, Aeotec Nano Dimmer, Aeotec Smart Switch 5 and 6, Aeotec Multi Sensor 6 and Trisensor, Remotec Zxt600 and 120 Ir transmiters for Split AC., Danalock Lock POPP Keypad, Qubino Single Relay, Heiman Temp and Humidity Sensor, Heiman Smoke Sensor, Zipato Bulb. I think that i didnt miss anything  , beside mqtt there is also websocket api. https://github.com/zwave-js
 

If you need someone for beta testing i’m available.

What is zwavejs2mqtt running on?

17 minutes ago, eon said:

Hello @david@berto.co.uk i’m using FGS-212 from Fibaro connected to a zwavejs2mqtt, the topic that this switch is using is z2m/Balcony/37/1/targetValue/set for control and z2m/Balcony/37/1/currentValue for feedback state. The payload is true and false only. So in mqttrelay driver im using z2m/Balcony/37/1/targetValue/set false and z2m/Balcony/37/1/targetValue/set true for control of the light and its working as expected. I tried http://www.chowmainsoft.com/relay-to-light connected to your mqtt relay and scenes - advanced lightning is working and the relay is controlled. But with your driver they are not controlled through scene - advanced lightning.

best regards

I need to add zwavejs2mqtt to my IoT gateway, looks very good. Does it support all the Fibaro devices?

Have made a fix to the relay light so hopefully scenes supported now.

Thanks

59 minutes ago, eon said:

I’m using zwave switch connected via mqtt, the relay light is connected to mqtt relay, i can switch on and off the light manually but when input it on scene is not responding.  If i manually activate the light the scene is reporting accoringly -active/inactive.

 

best regards

What is the model number of the switch? What are the payloads for the relay?

13 hours ago, eon said:

I”m device that is not supported by iot gateway and using mqtt relay connected to mqtt bridge to control the light. 

What is the device you are using? 
 
I’ll look into the relay light issue with lighting scenes as it should be supported. 

Thanks

On 8/14/2021 at 11:13 AM, ILoveControl said:

So been waiting for this for so long, yes you need to know how to develop your own drivers but now the options are endless. I have so many different devices that are on my main MQTT brokers that are not the C4 type devices i.e. Sonoff, Shelly, Wireless circuit breakers, other zigbee providers etc and this allows me to communicate and then program events in C4 based on the messages coming from the broker.

@david@berto.co.uk this really is awesome and opens a huge door for other developers to make use of this!!

Berto Cloud now has SMTP_SENDMAIL and MQTT_CONNECT,  MQTT_DISCONNECT and MQTT_PUBLISH functions exposed. Available at https://prod.berto.io/download/Berto_Cloud.c4z and example of how to use functions at https://prod.berto.io/download/Berto_SDK.c4z 

Thanks

18 hours ago, Don Cohen said:

Thanks - will check that out as well.

You could use either the Berto_Camera driver which lets you take a snapshot of the camera and email it or you could use the Berto_Cloud driver which lets you send emails with URL attachments either using your own email server or our Cloud service.

See https://prod.berto.io/download

Thanks