I just published a potential fix for this. The updated file is app_SimpleStateMachineInstance.groovy. The problem was you deleted a state that still had a transition to/from it. The app isn't preventing that yet, and it broke the page rendering.
1 Like
Thanks for that.
Still love the fact I can apply state machine logics, with your app. That often makes much more sense to me than convoluted if-else nesting.
1 Like
@jwetzel1492 If I may add a feature request here, after using it a while:
In most state machines one often wants to move from state X to state Y, after a timer elapses that starts counting once state X is entered, and resets when leaving state X. Let's call this condition "after". Often a transition is desired as an OR statement (so the after-condition is in fact a separate transition from state X to Y, next to any other already defined transitions away from state X). But sometimes as an AND statement (so the after-condition goes on top of an already defined transition away from state X).
An after-transition is also often used as a timed repeat. E.g. go from state X, to state X, after 5 minutes.
It would be nice if we could define "after"-transitions (with time as variable), directly from the app, in the state-transitions-table, just like normal transitions. That would make our external state machine logics we create in RM to activate transitions more clean, as well as save us from making (global) variables for all these timers.
Example: https://nl.mathworks.com/help/stateflow/ref/after.html
Additionally, I really would like the state-transitions-table to be on a new line, or in its own section, printed smaller, such that it still fits the page when it gets a little large.
I think any form of GUI in general would be nice, to edit the states/transitions more intuitively, but I guess the environment restrictions you get from HE makes this hard. Still, I think this would open up the app to people who don't have particular experience with state machines!
1 Like
I don't know how I missed this post. Your Simple State Machines app is brilliantly simple in its setup and execution. I've been using Node-RED for a state machine for one of my automations. It took me less than 5 minutes to convert it back to run on Hubitat!
Thank you!
Also tagging @erktrek because I think he uses a state machine also in NR.
3 Likes
I did not see this either!!! Will definitely check it out.
2 Likes
@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!
3 Likes
For #1, can you post a screenshot?
For #2, yes you are correct. No transition needed.
Glad it's useful to you!
1 Like
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.
Everything in moderation and balance...
2 Likes
Nice outfit, Eric.
2 Likes
1 Like
Here you go. See how 4 of the boxes in the table are populated, even though there are more transitions defined. No biggie.
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.
I would love to hand over this codebase to someone who wanted to drive it forward and had more free time than me.
2 Likes
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.
I'm also seeing the problem that @mluck had above - [BETA] Simple State Machines - #31 by mluck
In my case there are fewer states and events:
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.
4 Likes
I'll try to remember to create a pull request on this tomorrow.
1 Like
Forgot to update this - pull request created.
1 Like
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.
1 Like
Probably best to leave it to you to review and accept PRs for now.
I've done a bit of internal reworking already - mostly refactoring, and I'm working on renaming of states and events.
2 Likes
In case you don't spot the email from Github @jwetzel1492 there's quite a large pull request that adds renaming of events and states.
1 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.
5 Likes
