The Home Automation Controller Pyramid
-
akbooerreplied to rafale77 on Jul 4, 2020, 12:39 PM last edited by akbooer Jul 4, 2020, 10:42 AM
@rafale77 said in The Home Automation Controller Pyramid:
all the machine learning libraries seem to have a python API so it makes things much easier...
Yes, that seems to be the case. One AI application I use applies neural nets to image processing for astro-photography.
However...
... another big project at the moment (which has been on the “to do” list for a very long time), is a Prolog interpreter (written in Lua, of course.) I’m currently catching up on the last 30 year’s worth of scientific papers in the field of logic and constraint programming. Recently came across a 2017 paper outlining, what I consider to be, a real breakthrough in implementing the Prolog language, so that’s where my time is going.
If it all turns out well, it may even be included as an openLuup plugin! It also touches on this project...
-
@therealdb said in The Home Automation Controller Pyramid:
to be fair, ezlo seems to have implemented Zwave (and Zigbee) stack in a modern way. but I'm not convinced at all by their new programming environment. they're adopting an approach very similar to HA's, where you can launch scripts to intercept events, instead of having services always executing. So, openluup it's probably the safest bet in terms of features and stability for luup refugees.
More modern way than vera, no question. Anything else would have been pretty difficult to do but from my observation has been that they are still basing a lot of their focus on addressing the vera problems... which are very vera centric and no other platform has: They still want to go after devices one by one rather than look at zwave command class overall. I heard from other device vendors that they want to charge them to test their devices. They appear to be looking at a very closed and controlled device support environment and the whole idea of having a collocated mesh of controllers connected over IP as I discussed back at the old place displays their ignorance of how Zwave works. Again it is focused on fixing vera problems no other zwave system has, in a complicated way, "vera style".
But what made me walk away is the significant downgrade in the hardware vs. vera. A huge disappointment showing clearly that they tried to use the cheapest possible, ignoring reliability and future scalability (the i/o capability ranging from the bus to the ethernet chipset and the grade of the cpu and memory silicon are all downgraded vs the vera plus) and second the huge changes in the API which I felt was unnecessary and requiring a lot of work to adjust to the discontinuity to adopt something which is unreliable, not as mature in terms of feature and absolutely less scalable than what we have while many other solutions are available on the market. What is the point? They also seem to insisted on building their firmware backwards starting from the bling bling, eye candies at the top of the pyramid from 2 years ago and only now working on the core base which of course will delay everything because of the dependencies. They also definitely have gone cloud first which will makes the vision of having a cloud independent system much more challenging to implement. So indeed lots of pain (exclude include), lots of changes (plugins and API), to downgrade a system (hardware) to get a less reliable and scalable system which for now remains cloud dependent... no thank you. In comparison my migration to zway on openluup, though not plug and play involved none of the exclusion/inclusion, very few plugin and no API changes to get to much more scalable system on my own hardware (which I can later upgrade and move around) and has been cloud independent from day 1. It is much faster, more reliable, more integrated and scalable than ezlo can ever be.What they should have done was to put design a core firmware from the beginning (the base of the pyramid), release it on a much more modern and scalable hardware (something like an atomic pi or an nvidia jetson, or even stay on the vera plus hardware rather than a $7 board used for middle school lego projects), put all these UI and mobile app work on the back-burner and put their efforts on making the core radio control stack work on the same API as vera (put the second layer on top of the base of the pyramid). Then work on migrating all the existing plugin and integrations. These should have been done last year... and now they could have had a product upon which they could build further integrations, UI and mobile app at their leisure, having migrated over the existing vera customer base. They are currently a competitor for no one... though they see themselves as being competitors to even this forum which sells nothing... I have not followed any of their progress but really have lost interest since I felt they were heading full speed towards a dead end.
-
@akbooer said in The Home Automation Controller Pyramid:
@rafale77 said in The Home Automation Controller Pyramid:
all the machine learning libraries seem to have a python API so it makes things much easier...
Yes, that seems to be the case. One AI application I use applies neural nets to image processing for astro-photography.
However...
... another big project at the moment (which has been on the “to do” list for a very long time), is a Prolog interpreter (written in Lua, of course.) I’m currently catching up on the last 30 year’s worth of scientific papers in the field of logic and constraint programming. Recently came across a 2017 paper outlining, what I consider to be, a real breakthrough in implementing the Prolog language, so that’s where my time is going.
If it all turns out well, it may even be included as an openLuup plugin! It also touches on this project...
That would be awesome, I am myself thinking about eventually getting some of the video processing working directly on openLuup rather than going through home assistant...
-
@CatmanV2 said in The Home Automation Controller Pyramid:
2020 or 2021? 2021 seems more likely. Short sprints only means lots of progress if you're actually capable of writing code. Given the number of recurring issues, this seems something that may be beyond them.
- Short sprints mean more bugs for sure, but better ability to fix them as well. I prefer over the previous approach, we'll see.
@rafale77 said in The Home Automation Controller Pyramid:
What they should have done was to put design a core firmware from the beginning
we all know. I was just reporting that they did a good thing. It doesn't mean that the results will be enough, or in time to retain theri customer base.
Openluup seems to be the best viable solution for a smooth transition.
-
2020? That's 8 weeks away. If they can't even keep connected to a controller, it seems 'unlikely' that they can get a stable product out by then.
But what do I know
The joy of being Ops....C
-
It’s doable when you have engineers focused on things. I build complex systems for a living and with talented people you can write a lot of things in two months. Plus, it’s difficult to start. Once you have a codebase, bugs can be closed fast and features can be added easily.
I’m generalizing and I’m not sure they will, but, I’ll repeat myself, it’s doable. I think next two weeks they’re gonna release a lot of new features. The problem is some parts of their design choices are questionable, as @rigpapa already suggested in the old place. -
@therealdb said in The Home Automation Controller Pyramid:
It’s doable when you have engineers focused on things. I build complex systems for a living and with talented people you can write a lot of things in two months. Plus, it’s difficult to start. Once you have a codebase, bugs can be closed fast and features can be added easily.
I’m generalizing and I’m not sure they will, but, I’ll repeat myself, it’s doable. I think next two weeks they’re gonna release a lot of new features. The problem is some parts of their design choices are questionable, as @rigpapa already suggested in the old place.Oh for sure. I absorb(ed) the product for years. Yes it's hard to start, but if I was sitting in show and tell and hearing that feedback I'd be 'doubtful'
We shall see
C
-
Hi @rafale77,
Thanks for the diagram, it's helpful. But can you maybe tell me some more on the integration of Hubitat and Openluup? What is the best way to do it? I'm considering the move away from Vera, but don't know what to choose yet, Zway or Hubitat. Zway seems an easier migration, but Hubitat seems a great and easy all-in solution.
-
Hubitat will give you access to both zigbee and zwave but there is no bridge for it on openluup. This would mean that you would have to start everything from scratch and redo all of your home automation and go through a new learning curve. I have a few friends who run it and are reasonably happy with it. It isn't without its own minor quirks and is a relatively closed environment. It definitely isn't open source. A number of users have integrated it with home assistant to overcome some of its limitations and then used node-red on top for full control (thus completing the pyramid)
If you have devoted a lot your time developing your system, on vera then you are much better off with openLuup/ z-way which has very little learning curve except for the initial installation, which is more linux learning than anything, offers more flexibility and allows you to migrate all your scenes and plugins over to openLuup.
-
I have all my logic in openluup already, so z-way would indeed be the easy route. I also like that it is opensource. The only reason to choose Hubitat would be to simplify things. Thanks for your answer.
-
Yeah then it is a no brainer for your use case. We are also all here to help in case you need anything. I can't say enough to describe how happy I have been with the outcome of the migration.
-
@rafale77 I'm setting up Home Assistant at the moment, because of the wide variety of integrations. How do you use the integrations in openluup/AltUI? Is there a way to get the HA devices in Openluup? I could keep using AltUI then for frontend.
