Z-Way server support

[SphtKr]

Platform to support Z-Way server (e.g. for RaZberry).

Very early! Use at your own risk! May have compliance problems that disable your entire bridge!

Putting this out there in case anyone else was planning on building the same platform.

Z-Way server has its own HomeKit support, but it's lacking--pretty much only supporting binary switches and dimmers.

This platform bridge is already much more robust, and the initial goal is to also properly support thermostats and temperature sensors at least.

[SphtKr]

Also, I'm just seeing the "roadmap" and looking more into the HAP-nodeJS changes--I really like the new Characteristic class model etc...when can/should we start using that in platforms BTW, and do you have any examples in the works?

[nfarina]

Glad you like! You can use it immediately as of master branch a couple hours ago. See http accessory for an example - basically you just return an array of Service objects from getServices, instead of JSON.

For platforms it's the same - for Accessories returned by accessories async callback, they can implement getServices in the same way.

[SphtKr]

@nfarina, I'm getting kicked off the bridge after a few hours (maybe)...All of the sudden all my devices are unreachable, but if I stop and restart the bridge, it works again--though the old unreachable devices are still there and I have a duplicate set of new working ones.

Is getting an ECONNRESET still to be expected? Since there's no proper timestamps in the log, I'm having trouble correlating exactly where in the log my problem hits, but it might be around here:

HAPServer [CC:22:3D:E3:CE:36] HAP Request: GET /accessories +1ms
EventedHTTPServer [fe80::50:529f:414f:4a85] HTTP Repsonse is finished +3ms
EventedHTTPServer [::ffff:192.168.222.143] Sending HTTP event 'keepalive' with data: {"characteristics":[]} +6m
EventedHTTPServer [fe80::50:529f:414f:4a85] Sending HTTP event 'keepalive' with data: {"characteristics":[]} +0ms
EventedHTTPServer [::ffff:192.168.222.143] Client connection error: read ECONNRESET +15ms
EventedHTTPServer [::ffff:192.168.222.143] Client connection closed +1ms
EventedHTTPServer [::ffff:192.168.222.143] HTTP connection was closed +0ms
EventedHTTPServer [::ffff:192.168.222.143] HTTP server was closed +0ms
EventedHTTPServer [fe80::50:529f:414f:4a85] Sending HTTP event 'keepalive' with data: {"characteristics":[]} +10m
EventedHTTPServer [fe80::50:529f:414f:4a85] Sending HTTP event 'keepalive' with data: {"characteristics":[]} +10m
EventedHTTPServer [fe80::50:529f:414f:4a85] Client connection closed +53s
EventedHTTPServer [fe80::50:529f:414f:4a85] HTTP connection was closed +0ms
EventedHTTPServer [fe80::50:529f:414f:4a85] HTTP server was closed +1ms
EventedHTTPServer [::ffff:192.168.222.143] New connection from client +2s

And/or, have you seen this behavior?

[nfarina]

Yes it's still normal to receive socket disconnects as iOS devices travel in and out of the network. I've had my bridge up and running for a few days straight without any problems though; what hardware are you running the server on?

[SphtKr]

A MacMini, on the same switch as the RPi running Z-Way that I'm trying to code against. It's probably something in my code, throwing an invalid value or something. Just having trouble finding it.

[SphtKr]

Oh, not thinking...this (my dev copy) is running on a MacBook Pro on wireless, left on in another room. Particularly have you seen the behavior where the whole set of accessories gets duplicated, after which you have a set of unreachable accessories and a set of working ones?

[nfarina]

I did see it occasionally while reworking some of the HAP internals. But I haven't seen it for a while, particularly since I did a "Reset HomeKit Data" in Settings and started from scratch. I think I may have screwed up my HomeKit DB after so much testing. But I can't be sure.

Are you running iOS 9 beta?

[nzhome]

can we get a timestamp on the log output lines, because I too struggle to correlate some logs with time...

[nzhome]

yes its normal to get ECONNRESET when your iphone goes out of wifi range. i.e. you leave home and come back. but it doesn't bring the server down, and it will auto reconnect when its back in range.

[nzhome]

I have not seen any whole sets of duplicate accessories in any of my testing.

[nzhome]

@SphtKr your log posted looks completely normal to me, and nothing out of the ordinary there.

[nzhome]

actually do you have two devices connecting? in all my testing I only have one iphone. and only occasionally do I connect on other iphones and ipads to check the user sharing mode.

[nfarina]

@SphtKr You can enable timestamp logging in the debug library by piping output to a file. Take a look at the README for debug.

[nzhome]

Haha, yes today during testing I see a duplicate set of accessories.. it is not a problem though, it is the way you added them, it is supposed to work this way.

steps to create duplicate set:

• use default mac address
• add homebridge to mytouchHome (yep 1 set of accessories)
• reset homekit under settings->privacy,
• change the homekit mac address
• add homebridge to myTouchHome (yep 1 set of accessories)
• delete all persists files (two sets)
• change homekit mac address back to original.
• add homebridge to mytouchHome (yep wow now have 2 identical set of accessories half are greyed out, half are active.)

easy to reset though

• reset homekit under settings->privacy
• delete all files in the persists folder.
• add homebridge to mytouchHome (yep 1 set of accessories)

[volschin]

This is completely normal and IMO intended by design. If you use different usernames (MAC adress) you have different sets of devices. So you can add your development homebridge to a different room or home on the same account.

[SphtKr]

Hmmm...well, I'm getting the duplicates without changing the username/MAC/thing. I could try clearing the persists, that might help. Doesn't help me figure out why they're going offline in the first place :-/

I'm already using Burp proxy to monitor calls between my Platform and the Z-Way server...is it possible to make the bridge use a forward-proxy? So I could see the traffic between Homebridge and my phone?

@nfarina thanks, this was sufficient to get the timestamps to show up...in case anyone else comes looking:

DEBUG=* node app.js 2>&1 | cat

So technically, I'm really doing this to get debug output and node-debug for my own code:

DEBUG=HAPServer,EventedHTTPServer node-debug app.js 2>&1 | cat

[volschin]

Sorry, seems I have misinterpreted your sentence with default mac address.

[cflurin]

Hi,
timestamp can be added to your Accessory using a simple function:

Accessory.prototype = {
  mylog: function mylog(msg) {
    var now = new Date().toLocaleString();
    var logmsg = now + " [" + this.name + "] " + msg;
    console.log(logmsg);
  },

Replace the function here:

function Accessory(log, config) {
  //this.log = log;
  this.log = this.mylog;

Example: FhemSwitch.js https://github.com/cflurin/homebridge-shims

[SphtKr]

@nfarina Question: If I hit /accessories under the new API it looks like Characteristic.prototype.toHAP will get called before any get handlers in the accessory have been called--and that function just returns this.value, which won't contain any meaningful value yet.

I'm guessing we don't want toHAP to become async, should that call getDefaultValue instead? Do I need to include a value property in my Characteristic instance? Where does getDefaultValue get called?

[SphtKr]

Oh...I guess I definitely need to--I misread (more probably misremembered) the code in HomeKitTypes.js, and thought that getDefaultValue would be called after instantiation, not just during. So I need to give my Characteristic some starting value.

[nfarina]

Yeah the /accessories call must be quick (can't wait on async characteristic reads) so it uses the cached .value property of each Characteristic. This property should be set in the constructor if nothing else, based on getDefaultValue(). You can set it yourself by calling setValue.

[cflurin]

@SphtKr: Does the Z-Way server work with the USB Stick ZME_UZB1?

[SphtKr]

@cflurin I think it's supposed to, yes--that's the same company: z-wave.me . I have the RaZberry hardware from the same company, but I think it works the same way.

[cflurin]

Thanks, on the z-wave-me site I learnt that you need a licensing code for the stick (approx. 60 $). For the same amount you can get the RaZberry (The hardware already contains a valid licensing key inside the transceiver chip). By the way did your see the announcement: The new RaZberry Controller Software Version 2.0 now supports Apple HomeKit. ?

[SphtKr]

Heh...yes, see my first post/description of the pull request. The built in HomeKit support in v2.0-2.0.1 at least is not great, very limited. It has occurred to me that if this code gets good enough, they are within the license terms to just integrate it directly into their product ;-)

[SphtKr]

And yes, I think much of the "cost" of the razberry is the license. They sell a "bundle" with the USB version, the only difference is that you can't buy the razberry without the bundled license. Still, it's cheaper than any other commercial z-wave controller out there--the smart-things hub is the only one that comes close. And then you can run other stuff on the Raspberry Pi... Like Homebridge. :-D

[cflurin]

I did read your first post but I didn't remember the details. Sorry! during the last weeks I've read a lot about Homekit, homebridge and more. Just now I'm using the ZME_UZB1 with my mac mini for almost half year. I installed homebridge today on a RPi B and I'm thinking about to use it with Z-Wave devices.

[SphtKr]

@nfarina I think this is ready to merge...any last minute feedback? It's not bulletproof, but seems stable and supports a pretty good number of devices. A few more I want to add...but waiting on Amazon :-D

[luxus]

great! i just get my 4 thermostats (danfoss lc-13) and upgraded my pi with razberry today!.. the hardware installation took longer then the software part! everything is already working..