Jump to content

david@berto.co.uk

c4Forums Member
  • Content Count

    164
  • Joined

  • Last visited

3 Followers

About david@berto.co.uk

  • Rank
    Control4 End User

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Lukas, I might be bias but I have 42 Lifx lights, mixture of colour and warm white, and performance seems fine. There were issues with the new Lifx firmware a few months ago which are addressed in the latest IOT Gateway and Light drivers. The response time improved, mainly due to the changes in the way Lifx handle the LAN conversation. I also have several users running in excess of 80 Tasmota devices and performance is fine using the IOT driver set. See https://berto.io/src/Berto_IOTGateway Am now working on supporting Shelly devices direct using CoAP and avoiding the need for the MQTT broker. Thanks David
  2. Please beware that the current release is a major upgrade from version 13 and below and requires that you update the Berto Cloud driver first and then take the 'In Place Upgrade' option in the Service menu followed by a reboot. Some drivers have been obsoleted as they are replaced by a single group of IoT drivers so if you are using the Shelly, Sonoff, Lifx, Flic, Tasmota, Bluetooth, Google Assistant drivers you should look at the IoT Gateway driver. The Premium subscription plan option has finally been added to the Cloud driver and is now available. The Basic subscription plan remains in place and provides the same functionality as before.
  3. This is fixed in the current release.
  4. The Cloud driver does updates and installation as you say but also maintains a connection to the Berto Cloud service which provides other functions such as Google Assistant & IFTTT integration and also the free email sending service. All drivers should function without the need for an Internet connection.
  5. Yes. I normally change to 192.168.254.254 and manually number the cameras 1 to 16 etc. The the benefit is you can access all aspects of the camera via its actual IP address rather thank just it’s web interface.
  6. If you want to access the cameras on the 192.168.254.0 subnet you just need to set the default gateway on each camera to 192.168.254.1 and then set a static route on your router to route the 192.168.254.0 via the lan IP address of your NVR.
  7. Following Control4 dropping the CardAccess keyfobs I ordered an RF bridge, still waiting for delivery. I believe they’ll accept your existing RF remotes. Will be interested in the range. David
  8. I have a native Google Assistant service and driver for Control4 which is currently in beta. If you would like to test then PM me your email address and I will provide details. Thanks David
  9. No, it just does basic control of NowTV box. If I get time I’ll look at app control. Thanks
  10. I have a NowTV driver, see https://berto.io
  11. We use a cloud platform but its design, along with the drivers, ensures that connectivity to the Internet and the platform itself are not required for a driver to operate which I believe to be essential with any online platform unless of course the driver itself is an Internet centric driver. What issues do you have with the DriverCentral platform?
  12. Ping me a mail and I’ll send you the sample. What is the model of the 5ch relay you are using? Thanks David
  13. Lukas, Not a problem. I actually do have a sample MQTT Client driver that I can email you which provides a template of how you can interface to the MQTT bridge driver, if you send me an email, I'll pass it on. Thanks David
  14. Lukas, I've believe the problem is to do with IP Forwarding which gets turned off by my driver when OpenVPN is disabled, this happens by default when the driver is loaded. I've not be able to test fully but can see that the Navigator on the controller runs in an LXC container and requires that IP Forwarding is turned on otherwise the VM is unable to reach any network address beyond the controller itself. I've now removed this, as it is no longer needed, and will push an update, V9. The iptables changes you refer to is actually the insertion of a Masquerade rule, the same that is required for the LXC containers, so that the VPN subnet can receive traffic back from the local LAN when a client connects. Zuhair, thanks for your testing and support. You may want to check again after turning the OpenVPN server On/Off, not sure if you use or not but regardless the V9 update should sort the problem if it still exists. We don't use the master controller as a Navigator so have never seen this issue but will setup a test configuration to satisfy myself that it is fixed. Thanks for your help. Regards David
×
×
  • Create New...