Help With Dimmer Key Function Behavior (Toggle vs Memory vs Others)

I'm a little confused on the key functions for dimmers, especially eDLTs. I had a look through the programming manual but am uncertain on the details.

Setup: C-Bus network (relays, dimmers, CNI, DLTs, eDLTs etc.), Cgate and Cgateweb running on a Pi, MQTT (from Cgateweb) to home automation system (Homeseer).

Cgate and Cgateweb are functioning perfectly fine and I can control my C-Bus groups from the HA system and vice versa.

I notice that when using a dimmer, on an eDLT for example, that when you dim down initially C-Bus sends a 0 and then sends whatever level the dimmer is released at. When when you dim up a 100 is initially sent sent and then the dim level when released.

How do I stop this behavior? I would like short press on/off to work, and long press dim up/down but with out the initial 100 or 0.

The reason this is a problem is that I use some 'virtual' C-Bus groups to control non C-Bus dimming devices. But when dimming up with the eDLT the lights jump to full brightness (100) before dropping back to the set dim level. And dimming down they initially turn off (0) and then back to the set dim level. This makes level transitions very clunky.

Any help would be appreciated.

Marty

 

Dimming micro functions use Cbus ramp commands which give a target level and ramp rate. When you initiate a dimmer function it executes a ramp function to either on or off (i.e. 100% or 0%) at the specified ramp rate. This start the output unit ramping. While ramping, both the switch and output device track the value during the ramp. When you release the switch it sends a ramp command to it's calculated level with a 0Sec ramp rate. It does this to make sure all of the same groups in different output devices are synchronized.

The behavior you are seeing means that your 3rd party device isn't handling ramp commands correctly. That's what you need to fix.

Don't forget that when you initiate a ramp cbus has no idea when you are going to release the button.

 

Hi Ashley,
Thanks so much for responding.

The issue is I'm using MQTT and cgateweb in order to provide an interface to HomeSeer. So cgateweb sees the initial 0 or 100 and sends the corresponding MQTT message which in turn causes the 3rd party light (miLight) to jump to that value. And from what I understand from your explanation Cbus will then start ramping (which in turn I can see as a series of MQTT messages) and finish on the final release value.

I guess what I was hoping for was that there was a dimmer setting would not send any ramp command, just one message with the final release value which could be anything from 0 to 100.

I can live with the current setup but it doesn't look nice having the light levels jump around before ending up on the correct value.

I will have a closer look at the cgateweb code and see if can workout if it sees the incoming ramp and not just the endpoint.

 

If cgateweb is doing this then it's a bug and whoever wrote it didn't understand how cbus worked. That's really what needs to be fixed. I don't use cgateweb myself so can't really help there.

Also, I'm not entirely sure why mqtt sends a series of ramp messages. This is probably cgateweb again doing the wrong thing.

The point is that a ramp command is just 2 messages. One to start the ramp and the second to stop it. When you start the ramp you have to say which way to go, which is the 0% and 100% you are seeing. The device responding should just ignore those and start ramping. I'm not sure how you think it would work if you don't get the original message to tell it which way to ramp.

Are you getting a ramp at all at the moment, of just the initial 0/100% when you press the switch, then nothing until your release it when it goes to the final value?

 

Thanks again Ashley,
I am mistaken. I had a closer look at the MQTT messages coming from cgateweb and you are correct.

An initial 0 or 100 is recieved on pressing the button. E.g.:
"cbus/read/254/56/59/level=0"
Followed by the value on release:
"cbus/read/254/56/59/level=49"
So as you say, only two messages.

I was confused because the MiLight hub (beyond the scope of this discussion) is the device that sends a series of messages as part of it's 'transition' function.

When I get a moment I will take a closer look at the cgateweb code and see if I can do something.

Thanks for your time. It's great to have such amazing support on these forums. It adds to my confidence in CBus as digital lighting system.

I'll provide an update once I get to the bottom of this incase anyone else finds themselves in a similar situation.

Regards, Marty.

 

It was really good of Clipsal to release all the Cbus protocols because it opened it up to 3rd party integrators to provide new functionality. Unfortunately developers aren't very good a reading these documents so there are a lot of poorly implemented code out there.

I eventually just gave up on them and wrote my own

 

Yes, it's a double edged sword opening up protocols and APIs. Doing so provides new opportunities but also generates additional support queries. However there are a number of people who use 3rd party systems integrated with CBus (Command Fusion, HomeSeer, OpenHAB and various other systems via MQTT now). I can't help but think this would contribute to market share. Smart homes, by which I mean systems based on logic engines and not just 'smart wiring', are becoming a thing.

In our house CBus controls not just lighting but blinds, skylights, solar PV power diversion (via analog output), heating, extraction fans, pool pumps, and even heated towel rails. All these things are controlled by HomeSeer which uses all sorts of input data (weather forecasts, temperature and humidity sensors, rain sensors, solar array output, motion sensors, water temperature, room occupancy.....the list goes on) to make smart decisions to try and conserve energy and add automation. E.g. on hot days the system automatically opens the skylights and if is no one is home drops roller sunshades. Excess PV output is diverted to water heating. Humidity sensors control bathroom extraction, weather forecasts modify underfloor heating via the CBus HVAC application, boiler output is modulated based on number of heating zones active. Anyway, I could blab on for hours as I am a bit of a home automation geek. What I like about CBus is that should the automation fail you can at least still control most things manually. Cbus will operate in standalone mode.

I came up with a work around to the dimmer issues. When HomeSeer detects a change in the virtual Cbus dimmer group via MQTT for these specific devices it waits 4 seconds before sending the final value to the MiLight hub thus ignoring the initial 0 or 100. This introduces a 4 second lag but at least the lights don't bounce around. And the user can just use the slider graphic on the eDLT as a guide.

Sorry for the diatribe. Thanks so much for your time and assistance. If you get an queries in the future that relate to HomeSeer and CBus I am happy for you to send them my way.

Have a great week.

Marty.

 

I'm working with something similar here.
The string from a input device when pressed is "lighting ramp project/254/56/10 0 4" and when you release the button, it's something like "lighting ramp project/254/56/10 127 0". I'm grabbing the string and if the ramp time is not equal to zero, It's ignored.