Revisit: Scenes from M1g C-Bus Interface

Elk M1g owners who bought the Ness C-Bus interfaces some years back were disappointed to find that triggering C-Bus scenes is very rudimentary and usually involves work-arounds, e.g. use of spare Lighting Group Addresses to be detected by AC2 or PACA.

It occurred to me: the way it works is that when Elk sends individual "Lighting" commands with on/off or level to the C-Bus interface, e.g.

Code:

Set Back Hall (1 (A1)) Off, Fade Rate=0
Then Set Front Hall (2 (A2)) to 50% Bright, Fade Rate=0

the C-Bus interface firmware stores an editable Application (default = Lighting 56) per Address that gets put on the C-bus network with the Address and level from Elk. Which works well.

But since this Application is editable: why couldn't you change (say) addresses 100-110 to be Triggers (202) rather than Lighting (56)? Then when Elk turns on "Light" 100, it goes onto the C-Bus network as Trigger 100 with Action Selector=level. And suddenly you can trigger scenes. Yes that prevents the M1g turning Lighting Group 100 on or off, but that's no different from consuming spare addresses to get a scene to fire.

I would try it, except that the interface program only allows GA application to be set to 48-95. Not 202.

Am I barking up a wrong tree- meaning would replacing 56 with 202 convert a lighting message into a trigger, or are the message formats totally different?

If they are compatible - then perhaps somebody with contacts in Ness could ask whether they can add 202 as an option? Even if there is message incompatibility, interface firmware is updateable, so perhaps 202 can have a different message template.

All this assumes there isn't already a firmware update lurking somewhere that takes care of it(!) I'm revisiting all this after recent deployment of an AC2, now realizing just how many lighting GAs are consumed to activate scenes when Areas are armed and disarmed etc. There's a lot of M1Gs out there and it would be awesome if the M1g finally got the ability to fire scenes without having to waste group addresses.

 

Have you looked at the rules options in the cbus interface? They allow you to send trigger control and enable control messages in response to various events within the M1. You can also trigger a rule based on a text string sent from within an M1 rule. It's all described in the Cbus V3 documentation. I've never tried this so I have no idea if they got it correct. The V3 interface is quite buggy.

Yes. Trigger Control and Enable Control use lighting commands, just on a different application.

Good luck with this. Given that Ness hasn't bothered fixing any of the bugs in the Cbus interface getting new features may be optimistic.

 

Thanks, Ashley. I found that rules for Area arming triggers are very limited: you only get to specify one Area for all the rules, and if you want different triggers when the area is armed night versus away mode etc you're out of luck since you can only specify when the Area is "armed".

The programmed string looks promising, but how do you send it from the M1g to the CBus interface- presumably out the M1g's serial port 0, which is plugged into the C-Bus interface? Worth a try, I will report back.

Re bugs: I was a very early taker for the V1 C-Bus interface, ending up with all 3 versions that got swapped out by Ness over a very short period. In V3 I know there's a message "bounce" issue but apart from that, turning on a group for PACA and now 5500AC2 to detect seems pretty reliable. What else are you seeing?

It's also notable that when you add the latest M1g add-on for Home Assistant so you can control home automation and heating via touch screen, all the C-Bus lights registered in M1g are also automatically imported and turn up on the screen, so you can actually turn labeled C-Bus lights on and off without any programming and with no CNI or specific C-bus interface, and without the Cgate or MQTT add-ons. Very tempting- though not as robust as mqtt to 5500AC2 directly, by all accounts.