Sharing what I believe is a great way to add support to devices that used to work but since existing plugin haven't been maintain by the original authors (or any other developer in the community) have stopped working as they've abandon or moved to other platform...

Homebridge has a large and very active community and I think this type of plugin will a good way to benefit from it.

It will bring any device that have been configured in homebridge into openluup.

Currently it support, thermostat (Nest and others), Switches (Specially MyQ), Dimmers, Switches, Motion Sensors, Door Lock (Open/close) Support to other type of device can easily be added.

Homebridge2Openluup
Installation:

• upload the files to /you_openluup_directory/files/
• create a new device with D_Homebridge2openluup1.xml

• Set your hombredige IP, username, password to the deivce's attributes

• Capture the uuid of the device you would like to bring from Homebridge into openluup by looking at your openluup logs when starting

• based on the device type, set DeviceList Variable

T for thermostat
D for dimmers
S for switches
G for garage doors
L for Locks
A for motion sensors

and build a string device type are delimited by a ; (semicolong) and device's uui by a , (comma) like this:
T:homebridge_thermostat1_uuid,homebridge_thermostat2_uuid;D:homebridge_dimmer1_uuid,homebridge_dimmer2_uuid etc

This still in beta, would love to add async next and support to shades and other sensors.

@therealdb could use homebridge 2 openluup also...

I'm trying to monitor the indicator command class of a 5 button scene controller in Z-Way so openluup can properly create and track it.

seems like Z-Way COMMAND_CLASS_INDICATOR (0x87 or 135) are not being monitored by the ZWave module as I couldn't find anything for this command class in (/z-way-server-path/automation/modules/ZWave/index.js)

When a Get or Set Indicator command class request is sent to the controller. ZSniffer picks up the request and response just fine although this packets are not being monitored by the zwave module
Example:

ZWayIP:8083/ZWaveAPI/Run/SendData(NodeID,[ Command_Class, Instance, Value ])
ZWayIP:8083/ZWaveAPI/Run/SendData(2,[ 0x87, 0x01, 0x01 ]) (Hexa)
ZWayIP:8083/ZWaveAPI/Run/SendData(2,[ 135, 1, 1 ]) (Decimal)

the answer looks like:

[2020-04-24 19:59:36.261] [I] [zway] Waiting for job reply: Indicator Get
[2020-04-24 19:59:36.281] [D] [zway] RECEIVED: ( 01 0B 00 04 00 02 03 87 03 01 B6 00 C2 )
[2020-04-24 19:59:36.281] [D] [zway] SENT ACK

I’d like to store the Indicator response “RECEIVED” correctly. I believe by modifying the index.js of the zwave module could do the trick and once the module start tracking the indicator command class values as a metric then openluup's z-way plugin would properly track any changes as well.

I'm wondering if anyone around here could share any thoughts or comments that could make it easier...

@akbooer That's right... and just like that... apple is taking over then entire home automation industry.... too bad there is no Home app for Android. Well Front end and first layer voice control related...

thanks @akbooer . I'll be adding the installation instructions to the readme file... By the way, this plugin also works for ecobee thermostat, the native ecobee lua plugin by @rafale77 works ok when there is only one thermostat in the ecobee account but when more than one, ecobee server keeps deauthorizing the plugin...

@rafale77 I also use homebridge the other way (openluup to homebridge) and is great.

I'm currently using it for:

• Nest thermostats with google accounts.
• Ecobee accounts with multiple thermostats
• AUX Mini split with built-in wifi modules

Planning on adding control for AppleTV , Ring devices, Doorbird motion detection and many more...

It will allow us to finally include many of the popular cloud based devices that own into the openluup environment...

Something really cool about homebridge is that the manual and basic automation can be done from within homekit by the end-user, but deeper logic can be done from within openluup. Thinking about bringing node-red into the mix also... anyhow... I hope it can be useful for everyone here...

@crille pushed new fix for celsius. the plugin is now available on the altappstore.

@Crille I was using an older version. I have pushed a fixed to make device's name persistent after engine reload. please update the plugin and share the results when you get a chance.

Thanks @akbooer for the pointing this out.