Temperature sensors support

[JamesPickup]

Added support for the measurement type Digital Temperature Sensor Input Unit, 4 Channel

[JasonY00]

Hi James,

I was very excited to see your pull request as I have also been mulling over general measurement device (including temperature) in homebridge from cbus.

I downloaded your code and did some testing with some c-bus measurement devices (single temp sensor, 4Ch Current sensor and General Input Unit) on my network. I noticed that the temperature is picked up from c-gate from an initial get request, but I could not get the temperatures to change in response to a broadcast level change from c-gate. That is, the temperature (measurement) sensors broadcast changes over the network at regular intervals but I could not get the initial temperatures retrieved from c-gate "get" to change when I simulated a temperature change broadcast.

In my own attempt to achieve such support, the difficulty was separating the temp channel broadcast responses from a multichannel measurement device. I have the whole concept working for a single channel temp sensor but not multichannel which is what I want. That is, I can receive the broadcasts temps for each measurement channel from c-gate back into homekit, but am having trouble separating them back into their discreet channel accessories in homekit. (The same channel just changes four times quickly while the other three don't change from their initial "get" command!) If you can solve this then we are on a winner!

In order to receive broadcast messages in the measurement application 224 from c-gate you need to set the events level to "events e8s0c0" not e7s0c0. The broadcast data is presented in mantissa and exponent form and requires massaging. i.e. a mantissa x 10^exponent calculation. I noticed that for temperatures <10 degrees your values were out by a factor of 10 as its not a fixed exponent. i.e. I got 92 degrees instead of 9.2 degrees.

I hope to have time to look at it again soon as my kids are back at school next week. I think I have a few ideas from your code. There is definitely interest in this working. Would love to get it sorted. Would love it even more if someone else did it first :-)

Hope this helps

Cheers

Jason

[JamesPickup]

Thanks for the feedback Jason.

Setting the events level and listing for the measurement broadcasts is a better way to do this. Also, I tested temperatures < 10. Is displayed perfectly for me. I guess you are using a different c-bus measurement device.

I'm using:

• C-Bus Digital Temperature Sensor Input Unit, 4 Channel cat no: 5104DTSI
• application: 228

You're using:

• C-Bus 4 Channel General Input Unit cat no: E5504GI
• application: 224?

This is an example of the broadcast message I'm getting from cgate: { "time": "20200129-115132", "code": 702, "processed": true, "netId": { "project": "HOMEUNIT", "channel": 3, "network": 254, "application": 228, "group": 245 }, "application": "measurement", "sourceUnit": 15, "remainder": [ "data", "2681", "-2", "0" ], "type": "event", "raw": "#e# 20200129-115132 702 //HOMEUNIT/254/228/245/3 - [measurement] data 2681 -2 0 sourceUnit=15" }

As long as the 'channel' is added to your accessory attribute the hapServer should now match the channel measurement to the correct accessory. i.e. one accessory per channel in your config.js

[JasonY00]

Hi James,

great news re: the change in events level to 8. Glad it helped.

Regarding the parsing of the values from c-gate. In your example of:

[measurement] data 2681 -2 0 sourceUnit=15"

2681 is the mantissa, -2 is the exponent and 0 means temperature units in degrees Celcius (predefined in C-Gate).

So to calculate the value from above you need to say: data = 2681 x 10^(-2) = 26.81 degrees C.

This is the way that all measurement application [228] messages are formatted irrespective of the type of physical data being measured and transmitted over the network. If you look in the C-Gate2 directory (installed with Toolkit) you will find the CGateManual.PDF In this manual under the "Reference/Measurement Application" Section you will find the description of how this all works.

Bear in mind that some C-Bus devices have a Channel starting at 0 while some start at 1. So maybe allow for Channels from 0 - 4 (or 8 if you like) to encompass all C-Bus devices in your error checking code. If you do this, your Measurement accessory will work with ANY Clipsal Measurement Device, i.e. Single/Multi Channel Temp, Light Level, Current and General Input and you will be a legend for writing a universal Measurment accessory framework! Clipsal has about 30 predefined types of sensor indicated by the third data byte above. i.e. 0 = Temp, 1 = Current, 2 = Angular Displacement, 3 = Coulombs and the list goes on. This is also in the manual. I had thought of using this to set up measurement type definitions directly from C-Gate or using it for error checking but I don't have a lot of experience with Node.JS or time for that matter.

The only limit to displaying measurement data is that currently Homekit only supports Temperature, Light Level and Humidity naively. There are others like CO2 levels, particulate size etc, but for general environmental stuff these three are the most useful. Humidity sensors can be used with the C-Bus General Input unit.

Also remember that you cannot do logic in Homekit with Temperature. You will need to use a Homekit client like Elgato Eve.

Hope this helps.

Cheers

Jason

[JamesPickup]

Hi Jason,

I've made a changes to the temperature calculations and channel validation is now 0 to 8 channels as suggested.

The CGateManual.pdf has the measurement event format as: "[measurement] data device channel units multiplier value sourceUnit"

Although my event is in this shorter format: [measurement] data 2681 -2 0 sourceUnit=15

Perhaps a different accessory is needed for each measurement device?

I could write logic for the temperature in nodeJS. My rough plan is to write logic for my HVAC air conditioner to control fan speed and on/off based on weather temperature from the internet and temperature from the indoor c-bus temperature probes. I need to get my air conditioner on my c-bus network first though.

[JasonY00]

Hi James,

I can download your code and test again tonight. I can use my 4 Channel Current sensing unit as it changes constantly with changes in lights etc. going on and off so its a great way to emulate changes in temp. and the updating from broadcast events in C-Gate. The message formatting in Application 228 is the same with the only difference being that the data type is Amps instead of Degrees C and this is not tested for anyway.

As far as the anomaly in formatting in the manual re: order of data, I don't know, its written both ways so go with what you see from the real-time messages. It worked for me.

Looking forward to the kids going to be so I can test it!

Your code should also work with the C-Bus light level units and will only require the Homekit accessory to be defined as such. So you can produce both a Temperature and Light Level accessory with the same code for a commit to the homebridge-cbus repository.

As far as HVAC control goes, there were some devices going around that you could connect to your Aircon and control them with an app or with Siri/Google/Alexa but I can't vouch for how they integrate with the Home App. If your A/C has infra-red support you could also use the C-Bus IR interface to send IR codes. I used this approach with my old Velux Electric Skylights and some AV Devices and they work fine.

Cheers

Jason

Cheers

Jason

[JasonY00]

Hi James,

I have tested the temperature sensor accessory with a single channel Temp sensor, 4 Ch General Input and 4 Ch Current Input units all looking to homebridge like temperature sensors and they all work perfectly! They pick up the initial data via the get request and respond to all event broadcasts. The data/multiplier maths works for data < 10 degrees and channels from 0 - 4 for multisensory devices all work.

Awesome work. There will be some integrators in both this and the C-Bus forums waiting to apply this to their sites and I hope that Anthony incorporates it as soon as possible.

Cheers

Jason

[cbuscontrol]

Hi @anthonywebb is it likely that you will incorporate CBus Temperature devices into the plugin any time soon given the above update?

[BradJJ2000]

Hi @anthonywebb. I also would love to see this PR merged. Great work @JasonY00.

[anthonywebb]

I have pushed this up along with the other outstanding pull requests and tagged a new release 1.1.0, thanks for all the hard work on this one!

[JasonY00]

Hi Brad,

There is pull request here where JamesPickup has this working. If you want it now then head to his fork of this repository and download it from here:

https://github.com/JamesPickup/homebridge-cbus

Cheers

Jason

[JasonY00]

Thanks Anthony.

I wasn't sure if you were still maintaining the repo. I understand that c-bus is discontinued in the US for you :-( .I have a couple of other accessories that I have worked on. I added an invert option to contact sensor to cater for both normally open or closed contacts. Light Level, humidity, Occupancy (just motion with a different service), leak detector and a valve accessory (switch derivative) with the duration option. I want to try to put the duration as an option in homekit and not hard coded in the accessory. A garage door is the next to try, but it will need to incorporate a "pulse" for Open/stop/close and a second C-Bus Group Address for (open/close) status. If I can work out how to do two c-bus group addresses in the one accessory, then I want to do door, window and security as well.

Not sure if you have any time, but if you have any pointers, then let me know....

Node.js is not one of my core programming languages....

Cheers

Jason

[BradJJ2000]

I updated today and configured the temp sensors (working great!!) and I noticed a new log line on Homebridge start. One for each of the temp sensors.

HAP Warning: Characteristic 00000036-0000-1000-8000-0026BB765291 not in required or optional characteristics for service 0000008A-0000-1000-8000-0026BB765291. Adding anyway. (Repeated for each temp sensor).

As I said, all working great, but thought I would ask about the warning.

[JasonY00]

Hi Brad,

The code has one required characteristic for the TemperatureSensor Service which is CurrentTemperature. There is one other optional characteristic in the code, TemperatureDisplayUnits. This is in case someone wants to use Fahrenheit in their setup. Homekit assumes Celsius by default. This will be where the warning comes from. I was using an earlier version of JamesPickup's code without the TemperatureDisplayUnits and there was no warning. Just ignore it...

Cheers

Jason