@jwetzel1492 Joel, I've been using SSM for a little while now. It's so powerful and elegant. I'm surprised more haven't used it. It requires a level of abstraction that perhaps some people aren't comfortable with, but you get so much simplicity at the rule level in return, that I've found it to be a no-brainer.
Two things I noticed that aren't critical but just thought I'd share:
The table in the app that purports to show all the from-to transitions doesn't populate fully in my tests. I'm not sure I care since the underlying logic is working properly, but it doesn't "show" correctly in the table itself fwiw.
It seems reasonable to assume that one doesn't need to specific a transition between the same two states, correct? In other words, if State A stays at State A under certain events, that is implicitly the same as no transition and therefore does not require a separate transition to be explicitly defined. That's how the engine appears to behave, but I'm not 100% confident.
Again, thanks for this powerful tool, Never have I written so many trivial, one-line rules in RM. SSM is a complexity-killer -- frickin love it!
I agree state machines are awesome but can get complicated very quickly and it's easy to get caught up in trying to hammer in a solution where a simpler set of conditionals would work instead.
I'm amazed at how simple a state machine makes some operations.
I was thinking a natural extension to the rooms feature would be to automatically add devices from a room to a state machine for that room. It would then be a matter of picking the right box on that grid and defining an action. It would seem less like programing that way.
Have you had any takers on this yet Joel? If not then I'd be glad to give it a go since I'm no longer developing my LIFX drivers now that LIFX support is integrated into Hubitat.
I've just started playing with SSM and it's already solved a problem for me.
Ah, after a bit of logging I see what the problem is: when deciding whether to show the transition event you have the following code:
if (stateIndices[tFrom] && stateIndices[tTo])
The problem stems from one of those values being 0, ie the first state created. Changing the condition to if ((stateIndices[tFrom] != null) && (stateIndices[tTo] != null))
fixes the issue.
Thanks! I merged it in. I definitely welcome the help if you want to develop it more. I can add you as a collaborator on the project? Or just keep reviewing and accepting PRs. Whichever way you like.
If anyone wants to try my updates to the Simple State Machine Instance app while waiting for @jwetzel1492 to merge the pull request then you can install it from here - this is the only file that has changed over the previous version.
I would strongly recommended making a backup of your Hubitat since this makes an irreversible change to the internal state of the app (it replaces List<String> atomicState.transitionNames
with List<Map> atomicState.transitions)
The main change is that you can now rename states and events.
The last 15 years of my professional career included convincing co-workers that state machines were a far simpler solution to some of the problems in their (internal facing) software. Which was somewhat ironic, as the company's products include a suite of software for managing state machines and control systems.
I just saw this mentioned the other day in another thread and have just started playing with it. Many of my lighting automations are easily three or four state systems. E.g., in the finished basement, the lighting is controlled by three scenes: Empty, Entered, and Occupied. And I have confusing rules to control the transitions. I'm hoping this makes it all easier to handle.
I'm considering another internal change to SSM that will make managing the devices a bit simpler. The problem with the current arrangement is that the devices created for states and events end up all over the place in the device list, so I'm considering creating the states/events as child devices of a device named the same as the SSM so that all the states and events will be grouped together in the device list.
The other option is two devices, one for states and one for events. e.g. for an SSM called Tracker there'd be devices called Tracker:States and Tracker:Events.
What does everyone think? I'm hoping that I'll be able to retain the Device Network IDs for existing SSMs but I'm not sure I can promise that.
I think that it may be possible to iterate over the existing devices, renaming the old DNI and creating the new device with the former DNI then deleting the old device.
If that doesn't work I can probably still cope with maintaining an existing SSM since enumerating the state devices is done by a single function (and similarly for the event devices) which should be easy enough to modify to cope with either scheme.
