how to use custom characteristics?

[tvillingett]

How can i set custom characteristics from node-red, for example the type that Eve has for power consumption?

(see example here on row 38, for the UUID that the Eve App recognises):
https://github.com/Samfox2/homebridge-domotiga/blob/3319c01317a8b0e55af821869cdd81d19e3478d1/index.js

[cflurin]

The actual version doesn't support custom characteristics. It's on the todo list.

[ethan-phu]

how can i use the topic just like [homebridge/to/set],to set an TemperatureSensor of value's ?

[ghost]

+1

Let me explain:

I like to switch from several device plug-ins (Sony-Bravia tv, Yamaha amp) to mqtt and a python deamon. As with the device plugins the "string" chacateristic holds the name of the input like "HDMI1" or the name of the tv channel "NGC HD".

Within HomeKit (EVE does work with those, like some other apps, apples "home" does not) I can create scenes with the name "National Geographic" where I need to set the amp input characteristic to "Audio1" and the tv channel characteristic to the appropriate URI given by the TV.

Tinkering with the device plugins I was able to do this by creating a "STRING" type characteristic, where the props are set to READ/WRITE/NOTIFY.
if the channel is changed by the TV'S remote, the status is reflected in HomeKit on all devices but only If I use my own solution using my deamon/mqtt. And basically use homebridge as a connection to homekit/Siri without any of the plugins.

I have looked into the sources of homebridge-Mqtt. And as far as I can see the "STRING" values are dropped, which could be a quick fix. I am not really a nodesjs fan nor expert as 99% of my dev work is python related, the whole concept of prototypes confuses me a bit. Dealing with props of a characteristic seems in order except for the interface to the HB-Mqtt API.

As for now, hb-Mqtt seems to support all default types, defined in the hab layer.
If as a workaround I need to add my own services and characteristics in that file, that would be fine, except for it being in the wrong place (updates, new installations). To me HomeKit is fairly "open" in the sense of allowing custom services to be added although within certain rules. This plugin removes that capability. Like you said: it is on the todo list (and for that reason I guess).

I might be able to contribute, but with a lot of overhead (digging into the inner workings of this plugin and stuff like GIT, never forked and contributed to a project). Without these options I get a bit stuck in continuing building what is needed.

Martijn

[ghost]

I have confirmed the adding of my own types in HomeKitTypes.js and that the handling of STRING characteristics is broken in the repo as we speak. More info in a new posted Issue, where I report on how to create custom services and characteristics and found out that STRING support is an easy fix.

I am seriously considering implementing custom charactereristics an services to the mqtt API.
With that covered it is easy to implement an accessory based on say a esp8266, or arduino (with Ethernet shield) and it can automagically add itself to homebridge!

There seem two things which needs to be done:
1: Handle a payload Json to create a characteristic, setting name, type and props and Params.
2: Handle a payload json to create a service, setting name, characteristics and optional characteristics.

Topic homebridge/to/characteristic
{
name : "Source",
props : {format : "STRING", perms : [READ,WRITE,NOTIFY]}, //minValue, maxValue, minStep
UUID : "00000-00000-00000.....". // or generate in homebridge-mqtt ?
}

Likewise for defining a service.

Afterwards, the service instance can be made like any other. Additional management (remove/list) might be useful, not sure yet.

Any comments or tips might come in handy. Most of the code seems already there I guess just some additional glue seems needed.

Helmsman

[cflurin]

The string issue should be fixed with the new version.
Regarding adding characteristics and services I've to analyse the homebridge/hap code.
One approach would be to put the custom characteristics and services in a separate file (persistent) and add them to homebridge at init.

[cflurin]

A solution with a separate file:

1. build a file HomeKitTypes-Custom.js with your custom characteristics and services e.g.:

var inherits = require('util').inherits;
var Characteristic = require('../Characteristic').Characteristic;
var Service = require('../Service').Service;


/**
  * Characteristic "Current Air Pressure"
  */

Characteristic.CurrentAirPressure = function() {
  Characteristic.call(this, 'CurrentAirPressure', '00000102-0000-1000-8000-0026BB765291');
  this.setProps({
    format: Characteristic.Formats.UINT16,
    perms: [Characteristic.Perms.READ, Characteristic.Perms.NOTIFY]
  });
  this.value = this.getDefaultValue();
};

inherits(Characteristic.CurrentAirPressure, Characteristic);

Characteristic.CurrentAirPressure.UUID = '00000102-0000-1000-8000-0026BB765291';

/**
 * Service "Air Pressure Sensor"
 */

Service.AirPressureSensor = function(displayName, subtype) {
  Service.call(this, displayName, '00000101-0000-1000-8000-0026BB765291', subtype);

  // Required Characteristics
  this.addCharacteristic(Characteristic.CurrentAirPressure);

  // Optional Characteristics
  this.addOptionalCharacteristic(Characteristic.Name);
};

inherits(Service.AirPressureSensor, Service);

Service.AirPressureSensor.UUID = '00000101-0000-1000-8000-0026BB765291';

2. copy HomeKitTypes-Custom.js into the same hap-nodejs folder as HomeKitTypes.js
   (/usr/lib/node_modules/homebridge/node_modules/hap-nodejs/lib/gen)

3. add this line a the end of HomeKitTypes.js

var HomeKitTypesCustom = require('./HomeKitTypes-Custom');

4. restart homebridge

[cflurin]

... how to use:

add an accessory:

topic: homebridge/to/add
payload:
{
	"name": "netatmo",
	"service_name": "outdoor_temp",
	"service": "TemperatureSensor",
	"CurrentTemperature": {
		"minValue": -20,
		"maxValue": 60,
		"minStep": 1
	}
}

add the new service:

topic: homebridge/to/add/service
payload:
{
	"name": "netatmo",
	"service_name": "outdoor_pressure",
	"service": "AirPressureSensor"
}

set the value:

topic: hoembridge/to/set
payload:
{
	"name": "netatmo",
	"service_name": "outdoor_pressure",
	"characteristic": "CurrentAirPressure",
	"value": 1025
}

[ghost]

This is indeed what I do, except that I patch the configs in the homekittypes.js
I think it is better to move the homekittypes-custom to say the .homebridge directory as I am not sure what updates will do in the future.

As it is now, this is not really a homebridge-mqtt issue, as we patch a required library of homebridge. In fact this something hap-node should allow. At the other end, many plugins do create characteristics and service at init of the plugin.. I need to dig into it a bit further somehow this must be tackled in a way that does not confuse people after upgrades etc.

There is tons of code to be read, so be patient please.

Helmsman

[ghost]

I think I have found a solution on implementing custom characteristics and services. I might need Some help with forking this repo and putting the changes back. I have messed up something in git hub once majorly and never got a clue wat went wrong. First I must see if my theory actually works.

After I have a proof of concept, I will start some discussion about how to integrate this in the mqtt API.
The majority of the work will be some caching mechanism to recreate the custom characteristics and services at startup.

I'm committed to get this working, as said before It would be really cool and useful!

Helmsman

[CaptiveCreeper]

Would cfluin's solution make it possible to have both a fan and a light under the same accessory? So i wouldn't have to add two separate accessories for the same hardware accessory. For example if I add the characteristics for a fan and a light in the same service when it gets exposed to homekit would it have a light and a fan control or would I have to do something else to accomplish this?

[ghost]

I am slowly progressing mainly because I am not a Javascript/NodeJS fan nor expert.
I have added some routines to add new accessories and characteristics at runtime but I have no clue on how to test/debug them. Currently I'm in the mediterainian on a yacht.

@CaptiveCreeper: yes. In homekit a Accessory can have multiple characteristics this module supports that fully. If you scroll up, you can see a code example of how to Add a "Service" read that as "Accessory" and you probably have your question answered. I am adding some code to add the Service and Characteristics at runtime (probably over mqtt). This way an MQTT endpoint can configure itself for use with homebridge over MQTT via this plugin

[ihatemyisp]

@helmsman35 Any progress on your method to add custom services/characteristics?

I'd go with the method @cflurin said, but I worry it'll break updating homebridge or would be overwritten upon updating homebridge.

[ghost]

I sort of stopped using homebridge, since i’m a python guy and sort of hate prototype languages (like JavaScript). So I got rid of my nodejs Installation in favor of homeassistant. As we speak I am implementing HomeKit support for that. Homebridge has it all wrong, homekit is not a set of predefined stuff, it is open and extendable. Use the way @cflurin supposes with the single line include. That will be the only line to be added after upgrades.

…

Op 30 nov. 2017 om 00:20 heeft Ian ***@***.***> het volgende geschreven: @helmsman35 Any progress on your method to add custom services/characteristics? I'd go with the method @cflurin said, but I worry it'll break updating homebridge or would be overwritten upon updating homebridge. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[bohtho]

I agree with the above; HomeKit of course supports custom characteristics and services, not just Home.app (yet).

Have things changed since this with regard to custom properties? @cflurin

[bohtho]

Nick Farina just now on how to implement custom characteristics homebridge/homebridge#1453 (comment)

[iangray001]

@bohtho No, he didn't. He seems to have confirmed @cflurin's method, reiterating that Homebridge doesn't seem to support accessory-defined characteristics.

[bohtho]

You are right of course. I got momentarily confused. That would of course also be “ahead of time” and not dynamic custom.

[nfarina]

So just to try and clarify a confusing situation - custom characteristics really aren't very magical. Characteristics are just UUIDs with a small "props" dictionary that defines the kind of value they accept and some other metadata. The only magic is that all the characteristics pre-defined in HomeKit.ts have UUIDs that are known by Apple.

But you can easily, and at any time, create new instances of the Characteristic class (or subclass it if you want, but it's just syntactic sugar) with your own randomly-generated UUID and props. There's nothing special about it.

If homebridge-mqtt wished to support this, it wouldn't be infeasible, is all I'm saying. You could collect UUIDs and props via your JSON API and pass them along to Homebridge.

[bakman2]

@nfarina as far as I understand, only the "known" UUID's show up in the home app for anything else one needs to use an app that supports those ?

Looking at the netatmo plugin, it adds a noiselevel/dB icon to the home app, which is something custom but does shows up. How does this work ?

[nfarina]

So you can add all the "unknown" custom characteristics you want, and the main limitation is Siri won't know what to do with them. But you can still add them to Automations and Scenes and view their values directly in the Home app (if you know where to look).