Introducing PlugHub Energy - a smart hub with a built-in control hub

Indeed, if you have hardware which can handle it. As of now all the new products can’t do any of it. It requires a much more powerful cpu and more memory both ram and flash storage to handle all the plugins.

Just to note that openLuup can do this without any additional software running on the bridged Veras (I currently have three linked.)

It’s also worth pointing out that @amg0 has built a fabulous interface called AltUI (you should have taken up his offer to use it as the native interface) which also has the capability of integrating multiple controllers.

1 Like

Hi,

With AK and others here. Without openLuup and VeraBridge it would be a nightmare running home automation on more than one controller. So for the moment I am lost on the concept of many low cost controllers spread across a property. How would you do real home automation above the level of just remote control? Switching between controllers on the app to turn on a light is just a joke.

I’d rather have the Vera resources spend on a good quality central controller that can run my whole house without a release getting delayed because one person is out of office and then bricks all Plusses and Secures on the GA version after running just fine in Beta. Fix that and I’d stop referring people to other brands.

Cheers Rene

4 Likes

What is the vision and focus for the future? Is it this kind of devices? I’m guessing people who feel they are not the target audience would like to know…

1 Like

to create a whole range of controllers (including ethernet based) which can all work together as one and work natively in local mode with connectivity to all kinds of online services that works with every device, while reducing the cost of home automation for the consumers. That’s our vision.

1 Like

I have to say that I really like the vision and I think it is brilliant.
The problem is the path to get there. As of now it seems like almost everything you are doing is going in the opposite direction:
All the recent firmware releases increase dependency on the cloud. The first step to success for this is to have a clean solid base with both the zwave and zigbee network management and stack and a local API. These are foundations and are being grossly neglected in favor of cloud side dependencies (vera protect/mobile apps/linux firmware/7.30 firmware). All of your new devices are completely cloud dependent and can’t even be run locally, creating dependencies which will be very difficult to undo. The cloud layer needs to sit on top of the local layer. If it is the opposite, the local layer will be dependent on the cloud. Likewise, the local API needs to sit on top of the local engine (trigger, logic, action) and plugin. None of which we are seeing. Instead we are seeing all this remote access/cloud developments. This makes me very doubtful of the outcome. You seem to be building a pyramid starting from the top…

1 Like

Thank you @rafale77.

As to “how to get there”. It would be unfair of me to discuss this with the knowledge I have of all the development activities that you are not privy to. I can clearly see how we will get there because I can see all the development effort.

It made me think about a product I was looking to handle several protocols, like zwave, zigbee, Bluetooth and wifi… I think it is called VeraPlus😱

4 Likes

If I understand @melih’s vision correctly, a diagram of the network would look like this for zwave.

Each circle represents a zwave network and they would all be interconnected through IP. It basically extends the mesh by both enabling support for a lot more device and a much better range coverage. It relies also on a much higher bandwidth backbone of either ethernet or wifi. This is particularly helpful for setups limited in either mesh range or device numbers given that each network run by an individual zwave chip from silabs is limited in speed. It is brilliant for this particular application.
In this case you would only need one webserver/local GUI and have all the satellites only have a local API to be controllable. Given how cheap (hum, low powered) these satellites are, there is no way they could provide anything more than that.

The questions I have are

  1. Where does the zigbee strategy fit in all this?
  2. Trust and confidence in the ability to execute is paradigm and what I have been trying to express is that most of what we see in the early developments seem to go to opposite way of your vision due mostly to the dependance on the cloud. Why?
  3. For most (smaller) installations, you likely will only need the central hub and rely on the mesh which is both much cheaper and simpler to manage and would seem to be the base for everything. Should this not come first as the other satellite units can’t be tested without the center?
  4. In a smaller space, eventually these multitude of zwave networks will end up interfering with one another as the 900MHz bandwidth is limited. Thoughts?
3 Likes

So you want a new pickup truck instead of an old Plymouth sedan?

Ok, here’s 20 BMX bikes instead.

4 Likes

So the thought of this thread just came to me as I was observing my now very reliable network on zway which has a lot more tools to diagnose the zwave network.

I initially thought it was ingenious and innovative and I hate to rain on the parade but I have to say that the whole concept is flawed for zwave and is doomed to be unreliable:
zwave in each region only relies on 2 (World) or 3 channels (JP/KR), each playing a specific and assigned role. It means that from my graph above, if you have spatially overlapping mesh, they will interfere with one another with the HomeID being the distinction between the different meshes. The whole idea behind having a mesh is to avoid this multi-controller design forcing different meshes to share air time and therefore limiting there bandwidth. Granted a smaller mesh would require smaller bandwidth but it is a 0 sum game of number of channels, space and time and you would essentially gain nothing except for maybe in the case of very large and spatially spread networks where you could reduce mesh hops and also limit interference between meshes. For these cases, people usually have multiple hubs already. In case of interferences you will get increased retries due to CRC errors and corrupted frames, rendering the system slower and more error prone.

So it’s not just getting 20BMX bikes instead of the pickup truck. It is getting 20 BMX bikes attached together by the wheels and trying to get them to drive in different directions at the same time.