C-Bus lighting device

Although I don’t use C-Gate I would expect the event notifications would be accurate as other products that connect this way track status accurately. Polling really is to be avoided if possible.

One thing to be aware of is that the C-Bus network only reports state for ‘real’ groups. if you send a command to a group that doesn’t physically exist (often called ‘virtual’ or ‘phantom’ groups) then C-Bus wont report that new state in it’s MMI status messages. I am not sure if C-Gate handles this any differently. Real groups exist in output units like dimmers, relays etc. so I’m pretty sure Peter that yours are OK. ‘Virtual’ groups are often used to enable integration with other systems e.g. controlling a ZWave lamp from a C-Bus switch by allocating a C-Bus group number to the ZWave lamp. I have a lot of virtual groups in my system for exactly such purposes and as you integrate C-Bus with Vera you’ll probably find them useful too.

Sent from my iPad using Tapatalk

[quote=“XAPPO, post:21, topic:175506”]Although I don’t use C-Gate I would expect the event notifications would be accurate as other products that connect this way track status accurately. Polling really is to be avoided if possible.

One thing to be aware of is that the C-Bus network only reports state for ‘real’ groups. if you send a command to a group that doesn’t physically exist (often called ‘virtual’ or ‘phantom’ groups) then C-Bus wont report that new state in it’s MMI status messages. I am not sure if C-Gate handles this any differently. Real groups exist in output units like dimmers, relays etc. so I’m pretty sure Peter that yours are OK. ‘Virtual’ groups are often used to enable integration with other systems e.g. controlling a ZWave lamp from a C-Bus switch by allocating a C-Bus group number to the ZWave lamp. I have a lot of virtual groups in my system for exactly such purposes and as you integrate C-Bus with Vera you’ll probably find them useful too.

Sent from my iPad using Tapatalk[/quote]

I agree that polling is from the devil, but my thoughts were to implement the standard polling mechanism as we would see them with zwave nodes… There is now way we can guarantee that the vera and cbus states are always in sync purely by events from cgate, since either of the two systems could be ‘offline’ when an event is fired.

To that end the plugin would periodically (set by variable setting) every X minutes ask the cgate server for the states of all the groups in one command… This is an insignificant process for both vera and cgate.

That way, at least on the next poll cycle the nodes will all be in sync.

This of course is NOT for real-time event tracking, in other words not the solution to the problem that Pete has reported… I will find out why he is missing the events from cgate, once I get an extract from his log file.

I will however still implement the poll functionality, as I think it has it’s purpose.

T

At plugin startup on Vera it has of course to do a full synch with C-Gate but thereafter it should remain perfectly in synch, if C-Gate is subsequently taken down the socket connection to Vera would break, indicating a new synch was required.
There are some scenarios where the C-Gate to C-Bus link might get interrupted and I’m not sure how easy it is to get C-Gate to tell your plugin that such an event happened and a new synch should be undertaken and your approach would catch these.

Regardless, I had thought you were advocating a more intense polling to remedy Peters issue e.g. every few secs and that was why I posted. The poll you suggest at every X minutes is , as you say, insignificant and provides a good reassurance that everything is as it should be. So I think that’s a good call.

A heads up on one other aspect that you will have to decide how to approach…What happens when a group is dimmed to level 0 over a long period … say the 17 minutes max.Should you update the slider in Vera’s UI periodically to reflect the current level and more critically when does the actual state of the light change from ON to OFF. This has an important bearing on when associated triggers are fired , at the start or end of the ramp. I am not sure what the event data on C- Gate reports, and what a poll might return should that happen mid ramp. It may report a series of changes or not. The C-Bus direct protocol reports the final level immediately at the start of the ramp, so in my implementation as I preferred it the other way around I had to simulate the ramp changes and delay the OFF event.You might prefer the immediate change however and that is more in line with the way C-Bus itself handles it, firing an OFF event immediately the ramp starts even though the physical light is still ON for some time to come. The C-Bus event engines like HomeGate and the touch screens trigger that way.

K

K

Sent from my iPad using Tapatalk

I think the whole ramp issue is dependent on the events thrown by cgate as far as i am concerned. I will have to look at the events fired. I doubt i will implement my own gradual update of the level if cgate does not fire events.

I can see the semantic value, but not for what i aim to achieve. So I’ll put it in the wish list, but it will get a low priority.

Thx for the input… I still have lots to learn about cbus and how things work… Or don’t

Sent from my iPad using Tapatalk HD

Don’t take it as a wish list request on my behalf as my system sorts this by a different route … ‘WYGIWCG’ What you get is what C-Gate gives sounds a fine approach :slight_smile:

If either of you do have success with C-Gate on the Raspberry Pi … do please let me know.

Sent from my iPad using Tapatalk

Small update with some of the things we have discussed. More to come:

V1.02
26/08/2014

  • Added ‘ExcludeList’ Config variable use [] to identify comma seperated list eg. [1],[3],[14]
  • Added Message Handling for Getting TagName for Descriptions from CGATE
  • Added temporary mechanism for triggering TAGNAME cycle. Mixed Success
  • Modified Extract Groupnum function to cater for class 342 messages
  • Added StopDeviceEnumerate Variable. Set this to 1 to stop the CBUS device to re-initialise and add devices and update names.
  • Added processing of Dimlevel Tag in Tree Message 320. To set the initial state of the devices

Pete

I took look at the devices not updating the icon… This seems to happen after the first initialization when the group devices are added for the first time… After that they seem to work. I have found that with the latest change I made to set the initial status of the devices upon initialization, that this does not happen any more, and all the devices seem to update their statuses correctly, whether I set it on the vera GUI or from a CBUS device.

Let me know what you experience.

T

Yup, all seems to work well now, icons updating perfectly, excluded items all working perfectly. As you say, there is an initial delay when loading it the first time but after that a very quick response!

Starting on the Raspberry P this weekend.

Hi guys

I am working on implementing some standard functions not for the devices. Things that are missing or not working from the GUI:

  • Poll Node
  • Configure Node now
    etc

Also I am building some enhanced Actions and Events into the CBUS main node for use in triggering Automation.
Events

  • Raw CGATE Message
  • Actions
  • Reset
  • Send Command

I am also adding a variable to the cgate module to store the last message received for use in things like PLEG etc.

In theory you can use these to write some fairly enhanced automation scripts. I will post an update when I have something to share.

Let me know if there are any bugs to report or features that you thing we should incorporate.
It think the basics are quite stable at this point. I have been running mine without any hiccups for a number of days now, and it seems to be working nicely.

T

I have deleted my preceding post as I now think my issues were caused by running out of memory on the Vera Lite that I was using for testing. I need to restore and restrict the number of C-Bus devices I am creating as the Vera is now constantly rebooting (I have around 65 C-Bus devices created so far).

K

Hi Xappo

I don’t think there are any mem leaks in the code, but I would not be surprised at all. You guys are welcome too take a look at the code and point out anything you see with potential issues. I don’t even know where to start to track mem with the Vera. The device does not have much juice to begin with, so running into mem issues could be possible with that many devices, but I don’t think it should be.

I am running about 35 Cbus devices and another 30 mixed devices on my Vera, and it seems to be fine.

I will look into memory management and see if I can see anything I can do to manage memory better.

Regards
T

Hi, I don’t think it’s a memory leak… It’s just the available memory , especially on the Vera Lite, restricting the number of devices that can be managed. I’m not overly familiar with examining memory either but there’s a couple of plugins that should help me get better info to confirm this.

Sent from my iPad using Tapatalk

Hi guys

I have found a couple of times that the connection between vera and cgate has dropped. I am running a wifi link on that pc so it is expected. My recovery code works fine, except that it looses the command that you sent in the process. This is fine for when you are sending a device action from a GUI, since you can easily see that it failed, but when scenes execute you have a problem, since the device will not be in the state that you wanted it.

I will be implementing a change in the way that the device commands are sent that validates success, at least on a cgate comms level for now. Later I will try and do this on a group level, but this might be quite a bit more complex, and I dont want to break anything at this point.

Update coming this weekend.

T

Sent from my iPad using Tapatalk HD

Hi All,

Now have the gate running on a Pi quite successfully seems happily stable. Another step to moving the home automation running on its own systems :slight_smile:

Good news C-Gate is running OK on the Pi, I’ll give it a go.

What distro are you running and did you follow any particular thread on the C-Bus forum to do this ? I was rather hoping someone would post a SD image there but it looks like I’ll just have to take a deep breath and give it a go.

K

Does anyone know if there is a way to configure cbus so that I can use one of the cbus switches to start a vera process. It would be nice to be able to configure a switch on the wall to turn on a zwave lamp for example

Could you use an existing binary on/off switch to trigger a scene?

The Qubino devices have at least one binary input (the Flush 1 Relay has 2) that can be used for this purpose, but you would need to add a switch to the existing wall mount/cover.

Just out of interest (as I know little about CBUS Hardware), does CBUS use dedicated switches?

Yes… I’ve done this. You can create a group in Cbus. Assign a switch to it…

Then create a scene to trigger of that ‘virtual’ group. For my purposes I then switch the group off again to indicate the completion of the scene execution. It switches the indicator light off of the physical button.

Works like a charm.

I’ve got one button linked to my garage door, and with a fibaro relay module and door sensor, I can see the status (open or closed) from the indicator of the Cbus button indicator, and open and close the garage.

Just checking in and seeing if you’ve made any updates to your solution. I’m considering investing in a Vera and want to understand the complexity of tieing it into the cbus system

How do i go about installing this.

i tried to upload both files into the luup file section but do see anything after i have done this.