Ok… we need to replace the regex with:
r1:
binary_sensor\.[a-z]+_?(?:[a-z]+)?_door(?:_sensor)?
Those sensors was a real mouthful.
Explenations:
binary_sensor # Literal comparison. It has to be exact.
\. # \ means it escapes the dot. Dots is special in regex, it means any character \. means escape the special and make it not special, so dot.
[a-z]+ # Character class. At least one character in the span a-z. Had it been [a-z]* then it's optional. So no a-z characters or however many.
_? # optional underscore.
(?:[a-z]+)? # A character class that is optional, a-z at least one character.
_door # Literal comparison.
(?:_sensor)? # Optional literal comparison. So there could be a _sensor or not.
Regarding the function node.
I check if the first r1 is a match, if so send the message in the first (upper output) of the function node.
If the r2 is a match then send the message in the second output.
Else nothing.
Regarding the interior doors. That is not going to be pretty.
Since the naming convention does not include indoor/outdoor the pattern will match them too.
We could exclude office in the regex with:
binary_sensor\.(?!office?[a-z]+)_?(?:[a-z]+)?_door(?:_sensor)?
But if there is a bedroom, then that needs to be added also.
binary_sensor\.(?!office|bedroom?[a-z]+)_?(?:[a-z]+)?_door(?:_sensor)?
And if there is more… it becomes messy. (you just keep adding but readability is getting worse)
A different option is to do it as a direct comparison in the function node.
if(msg.topic != "binary_sensor.office_door" && msg.topic != "binary_sensor.bedroom_door" ){
if (r1 != null){
return [msg, null];
}else if(r2 != null){
return [null, msg];
}
}
Choose the one you find easiest to maintain in the long run. I don’t have any advice here.