@rob Consider adding this to HPM also.
That's already on my list 
3 Likes
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.
5 Likes
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.
4 Likes
Yeah child devices sounds like the way to go!
3 Likes
If it hasn't settled yet, I think I'd be inclined toward a single parent device with both state and event children. Less clutter in the device list, and they can still sort properly is the names start with "State:" and "Event:".
1 Like
@rob, is there a branch that contains the current version of all your updates? I see several unmerged PRs and a change discussed almost a year ago that I'd really like to have present before I start building around this. Also happy to contribute, but I don't want to contribute off out-of-date code, either.
Remind me in a couple of days and I'll see what the current state of my code is. I'm a bit too tired at the moment and I have a pub quiz to go to tomorrow.
3 Likes
Okay, my latest code is on GitHub - robheyes/Hubitat-Simple-State-Machines at mermaid-output
It looks as though the Mermaid export isn't working with the original device structure 
2 Likes
Some random thoughts, poking at this:
- Even though the events/states are in containers, Rule Machine doesn't surface them with the name of the container, only the name of the child device. If multiple state machines have the same event/state names, they're impossible to distinguish in the list. Perhaps the child devices should be prepended with the name of the State Machine?
- Renaming a state doesn't appear to work; it appears to do nothing.
- Removing a state results in "java.lang.NullPointerException: Cannot invoke method getLabel() on null object on line 355 (method mainPage)"
I think you're right about the naming, although maybe allowing the user to set some sort of short prefix might be better (or both, ie let them override the prefix)
I see what you mean about renaming a state, that used to work, not sure what happened.
Removing a state really shouldn't do that (obviously!).
If I get a chance to work on these this week I'll try to allocate some time to it.
1 Like
Brilliant bit of code lads 
Is this still ongoing?
Been too busy lately, I may try to do something with this tomorrow.
1 Like
