I just want to make sure that we are covering the original reported problem though.
If you use the Five Why’s method we are lead back to the root cause of the problem reported in this thread is that in the UI, the event Object is the Java event object and all the variables in it are Java Objects, not JS.
In order to avoid problems trying to, for example, comparing an OnOffType (which is what event.newState et al would be carrying) to the JS String "ON", Blockly adds a toString() call when ever it retrieves anything stored in event.
The problem comes in when that variable doesn’t exist. The call to toString() fails with a stack trace that is meaningless to the end users. That was the original problem in this thread.
We’ve added the undefined block which is great! It has uses outside of this specific problem. However, if we keep the call to toString() without a fallback we’ve not actually solved this problem. There is no way for Blockly users to actually test whether a variable exists in event prior to trying to use it and if they do use it they get an incomprehensible error in the logs.
If we get rid of the call to toString() we’d be able to test for undefined but wouldn’t be able to use that variable without further work to turn it into a String for comparisons.
We need a solution that both allows the user to test for undefined prior to use and not have to convert the event variables to a String themselves.