As of today I am using Pixelblaze for all my LED Strips lighting.
Step-by-step I replaced all my ZWave and Zigbee RGB(WW) controllers/strips with
Pixelbazes driving Addressable LED Strips.
This little toy is based on ESP32 CPU but has a lot of power. And BIG Thanks to @zranger1 it has ready to go Hubitat Driver.
Pixelblaze itself does require programming but the way how programming is
achieved is very user friendly and I would say - very simple.
I have now idea how this is done but Pixelblaze has Interactive Editor with
all error checking on a fly. The programming language is subset of Java which
provides enough Java-native functions for relatively complex programming.
Because this is text based editor you can easily use all Windows-native editing
functions and power. And because this is subset of Java you can easily create
logic with any complexity.
This approach may not play well with current Hubitat Platform at all but I think,
it will be very nice if future RM10.x can provide something similar to what
is achieved in a Pixelblaze in terms of programming (creating and managing rules).
Have you ever considered writing a custom Hubitat app? The language is Groovy. It seems clear that you have the skill needed for this, and it also looks like you prefer code (like Groovy) over a GUI (like Rule Machine, based on your frequent posts on this subject), so this really seems like something you should try.
(That being said, I'm not familiar with PixelBlaze, and some Googling didn't show me any sort of "wow!" interface, but I do see what looks like JavaScript, not Java, and again think you might be more at home with a Groovy app compared to Rule Machine if this makes you happy. )
Did you know that Groovy is supported in Hubitat Elevation, is a powerful Java derived programming language, has Java-native functions, and comes with a text based editor? This is part of your hub. You can even create powerful and complex apps with Groovy, such as, just for example, every built-in app including RM. This is more than an idea, it's a reality.
Are you aware that RM is an App that creates child Apps? Every Rule is an App that parent app to provide some or even all of the functionality.
This is true of Groovy as well. You'll often see descriptions on the web implying Groovy is wrapper for Java. If you need a prototype/template for an App, I have one you can start with, if you're looking to try Groovy.
Thank you for all yours time reading my crap and Thank you for yours valuable comments.
I am sorry, I was not very clear enough about what I was talking about.
Yes, I am aware about power of Groovy
I did look inside few Groovy aps, for instance this one:
What could be easier than turning All Lights/Switches Off?
However the above code looks say, not too friendly for the non professional sw developer.
Yes, I do have a lot of programming skills, and sure I could write something in Groovy.
But my point was: For the simple user, HE Programming should/must be as simple as
possible. Unfortunately as of today this is not a case.
RM is a very powerful App (Thank you, @bravenel ) but the GUI around it is unnecessary
overcomplicated and as result, is not really intuitive (i.e, it is not user friendly).
Many bugs (if not all) are related to the navigating through all these GUI menus.
I am sure, this could be simplified down to simple text editor.
My attempt to point to a Pixelblaze approach was not very informative because
I have no idea how to explain all details without actually trying it.
In short, Pixelblaze has built-in interactive editor which check on a fly all language
related errors (logic errors is a different story) and because it design to control
Addressable LED Strips you immediately can see what your code is doing.
This last step is not really applicable to the HE but something could be done
for quick test how code logic is working.
And I could be wrong, but to my eyes debugging Groove code for HE is also
not simple and intuitive. Error checking is done only on attempt to save code.
I did not go too far in this direction so I have no idea how good is error reporting.
Assuming there is no language related errors, debugging code logic will involve
adding a lot of log reporting code and navigating through all these logs.
Bottom line:
At least for the creating and editing Rules it will be very nice to have interactives
text based editor instead of current endless chain of GUI Menus.
Again, this is only my user opinion actively using Home Automation for more
than 30 years.
This is not at all a simple thing to implement. For example, as you observe:
So any attempt to write something like you describe is actually a not-so-simple undertaking. We're talking about thousands of lines of code
What you're describing is a language, and a compiler for that language. This is not child's play as you make it sound, but actually a very challenging thing to pull off. The semantics of such a language would have to capture the entire world of devices, events, states, relationships between them, variables, control of flow of execution, all while offering a syntax easy enough for someone with your level of skills to write code in -- oh, and error check while you write the code in this language. Even then, at the end of the day, the rule might still not do what you want due to coding errors, and you'd create things every bit as complex as RM rules, and you'd once again have a mess on your hands trying to fix it, just in a different representation.
You've posted this same criticism about 5 times now. How many more times are you going to beat this horse? It's become obnoxious.
In addition, Rule Machine is not the sole built-in rule creation app written in groovy.
If the goal is to make automation creation friendly to non-programmers or engineers, some type of point and click interface seems to be a given. Rule Machine has a complicated one. But Basic Rules has a much simpler one.
Here's a snippet of a basic rule that, I think, does something roughly similar to that example Groovy app called "All Off." This took me no more than a few minutes to create. And I have no training or experience in computer programming.
Use MakerAPI. Export some (all) your devices and events to the platform of your choice. Use the automation engines of your choice to create commands for devices on the basis of events from devices.
To be fair, the example you refer to isn't just "all off"--it's "all off with re-check," i.e., it will verify device states and retry if anything doesn't appear to have worked. (This itself is likely just a workaround for a device problem, but that's another story...)
A simple "all off" could be done with a lot less code, nearly all of which would be basically "boilerplate" code like what you'll find in that example--and any app (confession: I almost never try to remember all of that off the top of my head; I just copy and paste from a previous app...it's really not that daunting once you get past that). In fact, the line of interest would be as simple as myDevices.off(), and all you'd need besides that is an input to select what myDevices are, a method in which to put this aforementioned line, and a subscription or some way to actually run that method--again ignoring the "boilerplate"-type stuff, which is easy.
If myDevices.off() is more appealing to you than selecting Control Switches, Push Buttons > Turn Switch On/Off from a GUI, I'll again suggest, as many others also have, that writing a custom Groovy app may be right for you, and there are many people here willijg to help you do this. Rule Machine is not the only option--one could say it's there so you don't have to write code if you don't want to.
I would not mention this at all if I had not seen this in action by my own eyes.
I was very surprised to see this working on the ESP32 CPU without any
Cloud support in background. Everything is local on relatively limited hw resource.
Interface is a local Web Server (same as HE). And yes, it is an Editor + Compiler.
Everything is interactive and on a fly. I have no idea how all this is done but
this is a real implementation.
Please don't get me wrong again.
Pixelblaze is only $35.00
If you interested in to see this toy in action you can buy one and play with it.
Believe me, it will not be waste of money. There is a HE Driver for the Pixelblaze.
I replaced all ZWave and Zigbee RGB(WW) Strip controllers with Pixelblazes
and I am very happy because finally I can control LED Strips exactly the way
how I want to. This was impossible with all existing ZWave/Zigbee RGB(WW) controllers.
Now with HE + Pixelblaze combination I was able to do things I did not even thought
it was possible. As of today I have 6 Pixelblaze projects up and running.
I am sorry, criticism makes you very mad. This was not my intention.
I thought, criticism could be a driving force for making things better.
(This is how it works for myself.)
Unfortunately it worked opposite. I am so sorry.
I guess, I should try to write custom aps and drivers.
Many times I was thinking about this but what prevented me from trying - is a debugging
complexity. Maybe this is not that bad as I am thinking about.
Up to now all my sw experience was based on SDKs with interactive debuggers
with ability stepping through the code, brake points, variable watch, etc.
With the HE environment all what I will have for the debugging - is a lot of logs.
For the exercise I have a spare C5.
Is it any good some sort of Groovy Template for the beginners?
I am looking for something which will have all "must have" fields.
And where I can find a list of available built-in functions?
OK, I have something I really want to try.
My goal is get rid entirely from anything Cloud-based.
As of today only my curtains controls are depend on Cloud Services.
First one should/could be a custom driver for the Zigbee Shades.
(I specifically bought a Zigbee version.)
I can pair this motor with HE. Long time ago I tried every Motor Zigbee
Driver I found. Of course, neither one was working "as is".
That is a different game. We were all talking about apps above. The coding is similar between the two in that both are Groovy, but the way drivers work is a bit different. Part of the issue is also knowing how the device works at the Zigbee (or Z-Wave, etc.) level, and that's not something I can help with for that particular device. Perhaps someone familiar without Zigbee shades can.
Yes, I 100% agree with your statement.
For the aps I am all set (almost) with the RM5.x rules.
Frankly, I am not even sure which of the existing rule will be wise
to recreate as a custom app. I have to think about this.
But I do need few custom drivers.
And that Zigbee Motor is a very good candidate to try something.
So any help in this direction will be greatly appreciated.
It doesn't make me mad at all, but when done repeatedly despite numerous attempts by many people to explain this to you, it becomes an obnoxious thing. Have you read the responses you've received many times? What you describe is either (a) already available as Groovy (which you complain is too difficult because you would have to debug your code), or (b) is available as Rule Machine (which you complain is too difficult because you have to make many clicks to make choices), or (c) is available as Basic Rules (which apparently you have not tried). Instead, you conjure up magical and imaginary solutions which bear no relationship to reality. That is not constructive criticism.
If writing text based code is your objective, then you will have to deal with the fact that it will have to be debugged, that you will make mistakes writing it. That is, with text, unlike pull down menus, you can make many sorts of mistakes. Such mistakes can range from typographical errors, to ill-formed syntax, to just wrong idea. There is no magic bullet to make code be correct. As you have already discovered, with pull-down menus you can still make mistakes: mistakes of logic, of sequence, of thought process about constructing an automation. All of those potential mistakes exist for text based code also. There is no hand-waving that will give you what you seek.
Somehow we are speaking different languages (I am not talking about English vs. Russian).
I have no idea what is root cause for all these misunderstanding.
I am guessing, it could be cultural.
Drivers are indeed different although because the UI is the Device Info page, the Hubitat side is a lot of cut/paste.
As @bertabcd1234 said, the difficult part is getting the Manufacturer's Tech Manual that identifies the Zigbee commands needed.
I have a Driver Template I often start with:
It's a "complete" driver in the sense that you can paste it in and it compiles and can be assigned to a virtual device. The Device Info page is populated and there's a 30 min timeout on debugs included. However, it does nothing. It's a do-nothing-driver only. Everything you click on will be seen in the logs.
Is knowing inClusters and outClusters sufficient or I have to know something else?
I did not dig into the details but my simple guess was knowing In/Out Clusters should
be even enough for some sort of "automatic driver creation".
But if I have to know some other details in addition is a different story.
Google search for this specific motor did not produce any results at all.
I emailed manufacture my question regarding the spec but the above info is all
what I got in response. Better than nothing.
)
