Yes, I can completely back that view
And Marc happy new year. Let’s hope 2021 gets us some equilibrium
1 Like
Back atcha
1 Like
Nooo… Just “one press” => “+1 light bulb”, “double press” => “all bulbs”, etc…
Yeah, exactly like that. Right now just all lights turned one on 1% of brightness is to bright for some situations. And I using two groups. One of two lights, and one for 6 lights. But I want to have more control from wall switch.
No-no. I obviously want to know how to do things. If something will change my mind, I will gladly accept it. But, right now I am seeing YAML as programming with markup language, without easy way to understand it without cram every example you can find.
On other hand, to do something in almost any programming language, you just can know several simple concepts (variable, loop, function), and you already can do pretty complex things.
Real Code : -
It does not matter what code you want to use. You MUST have a User Requirement Specification (URS) if you want to program something complex. You are asking someone else to write this code but you need to convey how you want this to operate. I have no idea what you want.
You have 8 bulbs but you don’t say how they are wired, are they individually controlled (a switch for each ? Or smart bulbs ? ) or are they have grouped wiring ? (two bulbs per circuit etc.)
There are 3 switches, what do they connect to ? 3 different input switches ? Are they connected to any of the bulbs you mention (the 8 in the living room)
I am used to ‘users’ saying “here’s 3 switches and 8 bulbs - make them work” this implies that the software engineer has some mind reading ability, and though I’ve worked with some excellent software engineers (and quite a few crap ones) but none of them have an ESP ability.
We need more than what you have told us
As for the game bit - that is more complex, the software is for ‘home automation’ not particularly for split second decisions. But I’m sure we can do something.
You need to explain the full rules of the game, two players, two switches and 3 bulbs?
1 colour changing and 2 to keep score?
When do the bulbs give the scores ?
How ? - (say I have 3 points) off for 5 secs, on for 1 second, off for 1 second, on for 1 second, off for 1 second, on for 1 second - rinse and repeat ?
The colour changing aspect is difficult as you can’t (as far as I’m aware of any colour changing hardware) ask it to cycle and then read colour values back in, so you’d have to write a subroutine that changes the rgb values in steps with probably 1 sec intervals between steps - so quite a slow interaction and not very satisfying (again this is a hardware limitation not specific to HA )
How do you reset the game ?
How do you start it.?
This would be much easier if written to the UI (set input booleans (to start, stop, reset) display the score in numbers etc.)
What is the hardware ? Zigbee, Z Wave, esphome, tuya, gpio - a mixture ?
We are still in the dark here
What sort of software engineer are you.? Industrial? Commercial? Apps, PLC ?
I am developer in RnD department of online casino. For some time I was the only one, so I am full department. Most of my projects are for internal use: internal portals, stend-alone desktop apps, etc
Sorry, I was not thinking of this post, as for asking for someone to do something for me. Initial question was pretty much answered by @trankillity.
But here is USR addition:
- 8 Yeelight lights (YLDP02YL) connected directly to AC
- Two groups of 3 lights + 2 wall lights
- On wall I have battery powered Xiaomi Aqara Opple switch 3 bands (WXCJKG13LM)
- For game I have two additional wireless buttons from Xiaomi (WXKG11LM)
Perhaps not but there were people who supported your contention that yaml was incapable so to prove the capability we should do it.
The game would be crap given the hardware limitations on colour cycling so we should forget about that
But you need to describe the functions of the three switches and the resultant actions on the lights
Yeelights are independently addressable wifi bulbs aren’t they ?
So the diagram helps how ?
1 Like
I am a little surprised nobody mentioned Node-red here…
It’s not 100% coding, but it does allow data manipulation by neans of java.
Being a programmer myself (c++, c#, python, php, java) YAML is still jibberish to me…
NodeRed just make more sense to me.
But… i guess it is all personal 
1 Like
I’m surprised that you’re surprised. 
(It was mentioned; at least twice)
4 Likes
true…my mistake…
but what mwh said…
This is one of the things I really like about HA: There are all kinds of ways to accomplish something. When I started out, I was using Node-Red exclusively and writing some really fun functions. I started shifting over to YAML automations about a month ago and now I’m YAML exclusively. I haven’t ditched Node-Red. I can still use it to test-bed and prototype things.
I’ve also gone from simple Lovelace to a YAML-coded custom button interface.
I written a few scripts (Python), but I haven’t yet dabbled in the AppDaemon or Net Daemon (more Python and C#). Maybe sometime.
The point is, HA offers something for virtually every programming taste.
1 Like
That doesn’t look too difficult to implement with an automation.
Question: You have 8 lights but are the two groups of three lights supposed to be handled like two separate (grouped) lights or six separate lights?
In other words, when you single-press the switch to turn on an additional light, do you want all three in each group to turn on or strictly one light per single-press?
What is a USR ?
But that diagram doesn’t help
If the bulbs are Yeelight and Individually controllable
What difference (apart from sheer chaos) does it make that I can flip a (manual) switch to take out 3 of them ?
Like a URS … but with different spelling. 
1 Like
Oaky, I ddin’t get taht but if taht’s oaky tehn I’m srue to isaecnre my tpiyng effiicncey and rasie my wrods per muntie cuont
And that’s not a URS either
For me a simple URS would be : -
- There are 8 bulbs (bulb1, bulb2, bulb3, bulb4, bulb5, bulb6, bulb7, bulb8)
- There are 3 switches (sw1, sw2, sw3)
- Sw1 adds a light to those currently on (in sequence so if 1 and 2 are on, the next would be 3)
- Sw2 removes a light from those currently on but in reverse order (so 1,2,3 on sw3 leaves just 1,2)
- Sw3 toggles All lights on (ie, if 1,2,3 on then ALL off, toggle again and last state (1.2.3 reinstated))
Is that acceptable to you ?
Can we write code to that ?
The only danger there is to become a jack of all trades rather than …
Just curious. If you use NR for prototyping (I guess it’s easier/faster to program and expriment with automations this way) why your rewrite them into yaml? Any reasons why final “production” version of automation cannot stay in NR?
Less overhead. Automations by YAML are built into HA. Node-Red is an add-on that requires additional cross-communication between Node-Red and HA and overhead for the GUI.
To be sure, I was already spending a lot of time in the file editor honing my UI so in some ways it was easier just to switch files when I wanted to code or tweak an automation. I hadn’t actually noticed any lag in Node-Red.
Sorry (not at all my area) but - did you check CPU, memory, swap values before and after ?
Or maybe that won’t show significant differences unless you run without the NR Addon
Also dependent upon what hardware (I’d have thought a RPi3 to be the best metric platform (ie the most taxing) - dunno though)
Note: these are just made up numbers : -
NUC8i7 processor with NR 0.7% - without NR 0.8% (could be just rounding errors)
Pi3 with NR 14% - without NR 9% (not as easy to ascribe to day variance or rounding errors)
Again - I don’t know - I’m not in a position to test the two instances written with a house full of automations, one written in NR the other just with yaml
From the sounds of it, it seems like you are very new to HA. I’d suggest you look into the integrations. A light group will combine all these devices into a ‘single entity’, then from there you control what you want to do with a simple automation. You can even dynamically add or remove lights from groups, store scenes, etc.
Personally, I use appdaemon and have written many ‘apps’. But over the past year, the advancements in YAML and Blueprints have made the need for appdaemon diminish. I’m currently in the process of switching back to the built in automations. You might want to just give the automations a chance.
1 Like