@vezinpi said in Reactor-Editor / Reactor-ui-Status Errors: Not sure that it is the same issue but just got this on built 24302 when running a reaction for testing purpose. Despite the error message, the reaction ran properly. That was fixed in 24343. The reaction apparently runs long (lots of delays?), so it was causing the API to time out waiting for the reaction to finish. All works differently in 24343 and beyond.

@tunnus yes, the rule is working and @toggledbits indicated as such (that it would work) but he raised a potential issue regarding the crossing of midnight that I was asking about there being a better approach.

small update to align to 24343. https://gist.github.com/dbochicchio/825098ac13b7f8cac22012eae37ff7ce

@therealdb I have the hardware, just haven't had the time yet, to do exactly this.

Thanks to @toggledbits for guidance and the new option to capture response from actions into variables. It was quite fun to write this controller!

Ok, oddly, the correct lights came on last night.

@tunnus et al, please don't post screen shots of code/expressions or logs. Screen shots often end up displaying at a reduced size that makes them very difficult to read. Just copy-paste the actual text and use a fenced code block. To the question, as @therealdb said, judicious use of the coalesce operators will generally help here, particularly if you apply local knowledge of the desired outcome. There's another one that's often helpful when working with sources for numeric values that can be occasionally null: The ?# operator will take any left side expression and convert it to a number or the value on the right side, so someexp ?# -1 would produce -1 if the value of someexp can't be converted to a number or is null or NaN. In other words, the general form somexp ?# altval is shorthand for do local t=float(someexp), isvalue(t) ? t : altval done You can use this to produce, for example, an "off scale low" value that wouldn't trip a "greater than" operator on a trigger for a temporary missing value on an entity. This would let you write your expression more tightly as: round( getEntity( "..." )?.attributes?.current_sensor?.value ?# 0 * getEntity( "..." )?.attributes?.x_hubitat_extra_values?.voltagePhase1 ?# 0, 0 ) Note that the ?# operator has higher precedence than the math operators (like * and +) so you don't need parentheses around the subexpression in this case. That said, if it's specifically zero you're after where there's a null, you may not need to do anything special, because the expression language follows the JavaScript semantics for null in arithmetic: null is treated as zero (e.g. null * 8 = 0 * 8 = 0 and null + 8 = 0 + 8 = 8). So this could be written even shorter as: round( getEntity( "..." )?.attributes?.current_sensor?.value * getEntity( "..." )?.attributes?.x_hubitat_extra_values?.voltagePhase1, 0 )

@gwp1 I removed the link. Let's see if @gregbowers is a bot or not

@mrFarmer said in MSR UI on a mobile browser: Toggling the hamburger menu shows most pages except status. That rarely shows a widget especially in landscape mode. I would not think about making or changing rules on a small screen, but being able to look at the status would be nice. Found and fixed for next build. That sent me on a bit of a mission to try to improve the general appearance on the UI, even if editing will never really be fully supported (it may work, but I'm not going to approach it as a "mobile first" redesign, because I don't think that makes sense for this project). Here are some examples of work so far. [image: 1732556727781-screenshot_20241125_123614_brave.jpg] [image: 1732556727798-screenshot_20241125_123645_brave.jpg] This is a Samsung Galaxy S24 phone. Reduced top (nav)bar, menu moved from left margin to top and stripped of text. Columns removed from lists at this size. [image: 1732556840617-screenshot_20241125-123742.png] [image: 1732556840637-screenshot_20241125-123711.png] This is Samsung Galaxy S2 tablet. At this size, the menu returns to the left side, but still without text. The Status widget problem is fixed, and in addition, there was an issue where the Status widgets would drag if you touched anywhere in them -- they're only supposed to drag from their headers. Touch is still not working great on the phone (smallest size), but I'm still chipping at it, trying to find a workaround (the gridstack library controls the touch behavior, so I'm at the mercy of their choices and issues).

Harmless. Just a warning. I'll see about quieting it for the next build.

The error message will be improved, but for reference for future readers, there are two ways to fix this when it happens: Change the name of your local variable. Explicitly declare and initialize your local variable at the start of your expression as explicitly local. For example, assuming alpha is the name of a global expression/variable but we want to use it as a local variable name: local alpha=0, each e in matchEntities( { capability: 'dimming' } ): alpha = alpha + 1

@toggledbits thanks for the help. I will eventually improve this code and apply capabilities only if the device is somewhat new/changed or at startup. OpenSprinklerController is peculiar, but I think I could manage to achieve this result. This code is shared among my controllers, I've modified them to better handle updates. Thanks!