Is there a way to fix this behavior: I added a condition to an ever-more complex "Speak" "function/rule". The new condition is 'isAppropriate' which controls tons of other behaviors too according to varying conditions (time of day, volume of things, etc.) This "function" makes it simpler for me to control what verbal/notify behaviors other rules trigger and when they're allowed (and at what volume). As soon I added it, I got an error and have been unable to edit the RM 'Actions' since. Cloning it didn't help, nor did Export/Import. Here's the rule:
Here's one instance of the related log time window; didn't help me (don't yet know how to resolve object '22' to something meaningful having tried the Device tab's DNI switch and faffing with whether it's HEX or DEC):
The next step (assuming this error never occurred) was to add one final condition based on 'isAppropriate' to restore the volume to a usable value. I've manually overridden all the variables' values to ensure that isn't the root cause--didn't help.
Ideally, I'd like to export, edit/fix, re-import this rule because it took ages to create with the UX.
How do I remove an action when the error I'm getting prevents me from getting into the actions? If I could do that, I would've undone the change I made that caused the error--is there another way (such as exporting and directly editing the JSON--took a look; not obvious to me).
Events, Triggers and Action logging was already turned on. and posted.
I'm confused.
// EDIT: how do I resolve object '22' to a human readable form? I'm asking because, if I delete whatever that is, does that not eliminate the type mismatch error?
^ tried that--didn't work. Deleted every related variable, didn't work. So how do we have a type mismatch between two variables that no longer exist.
Do you have a backup you can go to? You could do a back up your current setup.
Then Restore a backup from when it worked, export the working version, then re-load your current backup and import the working rule.
It's a PITA but in my experience when you get those type errors it's usually a start over type situation. If the rule is simple enough you can just rebuild it, but if it's too complex then this may be your only other choice.
Appreciate that. I do take regular backups (some manual, one local daily and nightly cloud) and did so before deleting every variable to try and eliminate the type mismatch--I've since restored that one.
The problem is I'm making so many changes (due to porting so much stuff from other platforms, especially Alexa integrations) that I lose track of what I've changed and even my backup regularity isn't enough (nor should it be necessary). At least in this case--as much of a PITA as it is to recreate the RM rule--it's contained to a known loss that I can manually restore. However, that too shouldn't be necessary and certainly shouldn't be the only path back to 'working',
You're right, and we've been working at eliminating this sort of problem. The thing is, unless we can reproduce it, knowing the exact steps that cause it, it's not so easy to resolve. Do you have any idea what the last step was before it croaked on you? What string object could have had value '22', in what context? If the rule still runs, albeit with throwing an error, turning on Action logging and posting the logs would help. Or, is the error you're showing above just from opening the rule (not possible to tell from the logs you posted).
Yeah, I get that and I appreciate you acknowledging it.
None of the variable types were changed (not even sure that's possible given my limited knowledge of the platform) so the type mismatch didn't stem from that. The rule grew over time as I added conditions and worked well (after tweaks ) at each iteration.
To your question and as best I can recollect (confidence high): the last 3 changes I made were these prior to the rule breaking:
I can't fathom what string would end up with a value of '22'--that's the controlFlags variable but that's always been of type 'number'. The only string involved here is the sonosTTStext string which isn't part of the equation (literally and figuratively). All variables were global prior to my mod below.
All logging options were already active for my prior debugging so what I posted was it... there is nothing more I'm afraid. Apologies.
I posted the UX error that resulted from clicking actions and the repeated error samples from Logs--all prior errors contained no more detail; just a repeat sequence.
I've just finished recreating with a few slight differences... not helpful for RCA but FYI only:
