Add new "indicator" or "status" type?

[cmlpreston]

I was wondering if it would be possible to add a new device type that simply indicates the condition/level of a cbus group address (GA), with no option to change the status itself.

In my setup I have a security panel interfaced through the cbus network (via a minicentral board), and I am exporting the arming state to cbus groups (e.g. cbus GA 1 = "System Armed").

In homebridge, I can setup a light type and the status displays correctly (as a light), but this also permits me to (accidentally) alter the state of the GA, which is undesirable (i.e. I can change the apparent status to disarmed, even though the system remains armed). If I setup a motion or security type device in homebridge, then it seems that the status is only updated (in Home.app) when it changes, which may not occur for a while after a homebridge restart.

[simonhac]

@cmlpreston i have a minicentral myself, but it is not properly configured. i'm going to ask my installer to get it going, then i'll ensure that it is a first class citizen -- including more aggressive syncing of zone status. (i've played around with the CGate command for this -- it is very possible.)

apart from security zones, what other GA types would you want to map to an indicator?

[cmlpreston]

@simonhac The minicentral is a bit of weird thing (see discussion here: http://www.cbusforums.com/forums/showthread.php?p=56597 when I was trying to get mine sorted. I've just reprogrammed it again and I'm not convinced the programming has "stuck".

I've read and somewhat absorbed the NESS ASCII protocol (https://goo.gl/dNuRZx) which is how the minicentral presumably talks to the panel. The minicentral allows 16 functions to be setup in response to panel events. I'm not sure if that's what you mean when you refer to CGate commands. If not, I'm most intrigued.

As you say, zone status is of interest, as well as arming status of the panel. This isn't too hard to setup already with homebridge-cbus but the current device types sort of assume that you always want "controls+indicators" rather than just "indicators", which would be preferable when the arming status is mapped to a GA (i.e. you don't need/want to be able to change the status from homebridge connected apps as that would result in false indication).

[cbusguy]

I am also interested in this feature. I have a garage door with bus coupler to give me open / closed status, however i have the same issue with been able to bump it.

[simonhac]

@cmlpreston and @cbusguy -- i'm up for looking at this soon, but need some research first. perhaps one of you might be in a position to help?

i can think of two ways to do this:

1. add a readOnly attribute to every accessory in the config.json file, and modify homebridge-cbus to block any commands that would try to change the GA's state.
2. bind the GA to a particular HomeKit accessory -- but which one? if you can, please take a look at Apple's HomeKit Accessory Simulator and try to find a service that shows up on the phone with the best UX for an indicator.

thoughts?

[cmlpreston]

Hi @simonhac

Happy to help. I think your first option is fine and would accomplish what I had in mind. I'm also happy to checkout the other accessory types. I've made it to https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/HomeKitDeveloperGuide/EnablingHomeKit/EnablingHomeKit.html#//apple_ref/doc/uid/TP40015050-CH2-SW3 but got a bit stumped. I do have Xcode install but it looks like you need to have source code for an app to be able to select the accessory simulator capability.

I'll see what I can google up in terms of various HomeKit accessory types.

[simonhac]

thanks @cmlpreston for looking into it.

I do have Xcode install but it looks like you need to have source code for an app to be able to select the accessory simulator capability.

unless it has changed recently, this shouldn't be the case. i have downloaded the simulator and don't have any source code.

[cmlpreston]

So here's the list of service types, I assume: https://developer.apple.com/reference/homekit/hmservice/accessory_service_types

And here are the category types: https://developer.apple.com/reference/homekit/hmaccessorycategory/accessory_category_types

And here's a picture of Craig with the types! http://photos2.insidercdn.com/gallery/17336-14749-Screen-Shot-2016-06-22-at-84103-AM-l.jpg

I note there's a garage door type, which might interest @cbusguy .

[cmlpreston]

Ok, found it in the downloads of developer.apple.com. "Hardware IO Tools for Xcode 7.3"

Trying it now.

Ok, so I gather you add some accessories in the simulator and then find them in Home.app (etc) to see how they behave.

[greiginsydney]

Hi @simonhac. I'm back! (I've been in hiding).

+1 from me on adding a "Read only" tag. I also have some dummy GA's reporting various states around here like a mimic panel would, and I'd love to be able to have them accessible in Home without fear of accidentally toggling them. (Some I might be monitoring a real channel, but one that I trigger indirectly via code in the PACA).

• G.

[Nivin37]

I would also like to be able to monitor GA's as well.

[JasonY00]

Not sure if anyone still interested in this, but I added the contact sensor and smoke sensor to homebridge for this reason. The motion, smoke and contact sensors (that can be portrayed as door, window, garage door, gate, etc) only monitor a c-bus group address as ON/OFF or OPEN/CLOSED but cannot be changed by the home app.

Incidentally, most of the sensor types in homekit work the same way as the ones above. It comes down to what sort of icon you want.

Hope this helps

Cheers

Jason

[cmlpreston]

Fantastic. I was just looking at this new sensor type last night wondering about it. To find out that it addresses this topic was interesting. Even more interesting was to discover that I requested it 3 years ago and have little memory of such!!

[JasonY00]

Give it a go...hopefully its what you wanted.

The contact sensor type can be portrayed as Garage Door Opener, Door, Blinds, Contact Sensor or Window. (Window includes a skylight icon and blind includes a retractable awning icon).

I have played with an occupancy sensor type that is almost identical to motion sensor and created a leak sensor that I use with a rain sensor I have. (neither sent as a pull request yet). I have also done a light level sensor and humidity sensor (for a c-bus general general input unit). This was derived from the temperature sensor.

There are a few other types that could be integrated into homebridge-cbus like faucet(working on this one with a timer), door, window, and garage door. The last three are more difficult because to make them work you really need to have one cbus group address connected to an auxiliary input or bus coupler providing the open/close status and another group address that provides the ON/OFF command. In the case of garage doors or gates, this may be a "bell press" connected to an O/S/C connection on the controller. I am trying to work out how to do this in the current framework of the homebridge-cbus plugin.

Will keep trying...

Cheers

Jason

[DarylMc]

@JasonY00 Nice work. I look forward to checking it out.

[JasonY00]

Thanks Daryl,

I'm not sure if the garage door, door and window are beyond my programming skills in node.js at the moment.

Integrating the status of an already defined c-bus GA accessory in homebridge and incorporating it into another homebridge accessory with a new cbus GA is where my perceived challenge lies.

Homebridge has to be in insecure mode (which it is) to get the status of an already defined accessory. I would need to work out how to do this with the UUID or name of the accessory, accommodate for events (ie state changes) from that accessory (for status) and merge it with the new accessory that triggers the OPEN/CLOSE/UP/DOWN action.

I also want to keep it simple in the config.json file, stay within the scope of the homebridge-cbus plugin and not break any of Anthony's programming.

If anyone reading this has any ideas, I will be happy to hear them...I expect that my progress will be slow.

Cheers

Jason

[DarylMc]

@JasonY00 I use a plugin on a standalone RPI with a relay board attached to the gpio. https://www.npmjs.com/package/homebridge-gpio-relay It seems to have a decent implementation of security for a garage door. Can close the door without authentication but needs authentication to open it. Has inputs for upper and lower limit switches. Does notifications. But it has not been updated and only runs on old versions of node and only a certain version of the now obsolete wiringpi. I’m keeping an eye out for another alternative.

[JasonY00]

Thanks Daryl,

I will have a look at the garage door plugin you mentioned for ideas.

I want to, as much as possible, stay within the C-bus I/O. That is, accommodate as many HAP accessory types as possible to work with C-Bus and not use pi I/O. So if you have any type of dry contact sensor type connected to a bus coupler or Aux Input, where possible, I want to display it with an appropriate icon. There are several sensor types that fall into this category. If its a sensor type input that provides a real world value, eg, temperature, humidity, light level from c-bus, well its the same idea. There are not a lot of great options for sensor types in homekit. For example, there is no current, AC or DC voltage, Power, and lots of others that would be useful. Some are supported in Elgato Eve, but won't display in the home app.

As an example of a more complicated accessory that I want to implpement, take the garage door for instance. It needs to have three "required characteristics" to be defined to work properly:

1. C-Bus GA input <-> CurrentDoorState - Reed switch to Aux Input
2. C-Bus GA Output <-> TargetDoorState - C-Bus Relay (that also accommodates O/S/C bell press operation)
3. C-Bus GA Input <-> ObstructionDetected - another C-Bus Aux Input to the Normally Open contact in the door obstruction sensor.

The above config needs to be defined in the one accessory in homebridge.

This isn't how the homebridge-c-bus plugin generally works. It's a one to one mapping with only one C-Bus GA mapped to one required characteristic within one accessory and doesn't usually define any optional characteristics. The one exception that does use optional characteristic is the dimmer accessory (brightness). But it still uses only one c-bus GA.

My current level of understanding of the code prevents me from doing accessories like the garage door opener at the moment.

This is what I am thinking about...and will keep plodding along...I reckon that someone like Anthony would be able to nail it!

Cheers

Jason