No… by yelling I wasn’t referring to your loud constants but the image 3 posts up! I don’t exactly know why that transaction was so hilarious for me, but it still makes me giggle!
Thank you for the heads up. My rules are parsing the NOTIFICATION value for LOCK and UNLOCK, so this change will not affect them.
You already provide the TYPE separately. IMO, it would be cleaner to remove the TYPE from NOTIFICATION so that it would just be the human readable EVENT name. Sorry to have not suggested this sooner, but I wasn’t actually planning on using alarm_raw until I was testing it out and realized that the EVENT numbers could be the same for different TYPEs.
Does it still make sense to have both the notification_access_control and alarm_number channels?
What do you think of a raw event channel, similar to alarm_raw but rawer? This could be provided for all devices, even ones not in the db. Then rules could be used to interpret the event, and perform actions or update Item states. Having the channels packaged up in the binding is very handy, but at times the purist in me just wants the raw data so I can shape it myself, without having to mess around in the binding.