integrate with #thethingsystem

[mrose17]

hi. i just pushed an update to the repo for the steward that has the scaffolding you should need. i believe you can focus on the file gateway-zigbee-xstick.js

i think we need to work this in two steps:

step 1: add more scaffolding to that module so that it's ready to make calls to the internal steward APIs saying "i discovered this device" or "this device has updated its parameters"

step 2: i'll write a driver for one of these devices and hook it into the scaffolding. at that point, we can go through the list of devices that you have and i can show you how to do a driver. it's not that complicated.

ok, here's how the gateway-zigbee-xstick.js file works:

the start() function is invoked after the module is loaded. this defines the prototype function for /device/gateway/zigbee/xstick2-zb and then starts a function called scan that runs every 30 seconds.

the scan() function looks for USB devices matching a set of "fingerprints" that correspond to the digi stick. when a new one is found, it call invokes a callback within scan() that calls the internal API to discover a new device (in this case, the stick).

this results in the Gateway() function being new()'d to create an instance of the device driver. first, we have a bunch of instance assignments, then the driver subscribes to the 'actors' channel which is used to convey information about perform requests (among other things). if a perform request comes in for this particular device, then the perform() method is called.

both the validate_perform function and the perform() method are driven by Gateway.operations, an associative array. if the thing to be performed is a 'set', then this is handled internally, with devices.validate_perform, and the super method devices.perform(). otherwise, operations{} indicates how to proceed.

so, that's the scaffolding, now the part i'm clueless on. in the bottom half of the Gateway() function, there is a chained list of self.xstick.on() and self.xstick.zbee.on() handlers. this is where you need to add code that will figure out that zigbee devices are available, what kind of devices they are, and then get ready to invoke the internal API in the steward to create the corresponding instance.

does that make sense?

thanks!

[antamy]

Thanks for the update! I've been working on another project and put this on the back burner, but will take a look at these updates later this week.

[stormboy]

Great. I'll look at it over the next few days.

[antamy]

So I got this installed on the Pi and it finds the digi-stick. mrose17 had that working previously, so not sure if I'm supposed to see something different. Where is gateway-zigbee-xstick.js? I've searched in your node-zbee repository and in the one for the Thing System and can't find it.

It would be handy to see what a driver looks like. My devices will all be custom built, so I was hoping there was a framework that they could be plugged into - specify their addresses and capabilities in a file and off you go.

[mrose17]

the file is in the steward repository, vIz.,

     cd steward
     git pull upstream master
     cd steward
     npm -l install

in terms of a driver, I need to see what happens in step 1...

[antamy]

So are you going to be focusing on Zigbee HA devices? As far as I know, devices that use that standard are the ones where you can query their capabilities. Or are you going to support arbitrary devices where a config file tells you the capabilities, and the scaffolding just tells you whether it can connect to the device or not?

I was just looking for the latter, and then be able to write a simple driver that interfaces with the actual device via the digi stick.

I'll pull down the code and take a look. Maybe I misunderstand github - I though I could just go to github and search all repositories for the code, but that doesn't find anything.

[mrose17]

once it is running, you'll be able to register arbitrary devices based on characteristics. it will look something like the code in gateway-openwave-usb.js and switch-zwave-onoff.js

[mrose17]

@stormboy - hi! any motion on this? just checking!

[stormboy]

@mrose17 I'm going over this today. Having problems installing the node modules for the steward. noble fails compilation on Mac (Mavericks). I've tried making sure Macports gcc is used instead of clang.

CXX(target) Release/obj.target/binding/src/XpcConnection.o
cc1plus: error: argument to '-O' should be a non-negative integer, 'g', 's' or 'fast'

[mrose17]

@stormboy - thanks very much, i appreciate you making the cycles available.

also, meet @sandeepmistry, the author of the noble package.

sandeep - could i ask you to help @stormboy get noble compiled on his mavericks system… he's doing the zigbee platform, which i am very much looking forward to.

[stormboy]

Weird thing is I can do this:

git clone git://github.com/sandeepmistry/noble.git
cd noble
node-gyp.js rebuild

But I cannot do this:

npm install noble@git://github.com/sandeepmistry/noble.git

It might actually be xpc-connection that is the problem:

> [email protected] install /Users/stormboy/src/steward/steward/node_modules/noble/node_modules/xpc-connection
> node-gyp rebuild

  CXX(target) Release/obj.target/binding/src/XpcConnection.o
cc1plus: error: argument to '-O' should be a non-negative integer, 'g', 's' or 'fast'
make: *** [Release/obj.target/binding/src/XpcConnection.o] Error 1

[stormboy]

OK, looks like this module is assuming clang on Mac. I've removed gcc and g++ from the path and it compiles.

[stormboy]

Now I am getting this when running the steward:

Assertion failed: (handle->InternalFieldCount() > 0), function Unwrap, file ../src/node_object_wrap.h, line 61.
./run.sh: line 102: 26247 Abort trap: 6           node index.js
Press ^C to exit or wait 10 seconds to restart

[mrose17]

crikey! let me see if i can reproduce that… i haven't seen it, but someone else has...

[mrose17]

well, i brought the steward up on mavericks and didn't get the assertion failure.

let's try an experiment: move all of the files in devices-climate and devices-lighting somewhere else and try run.sh again. let's see if that avoids the issue. (i'm searching in google to see if i can find something…)

[stormboy]

After moving those files, it doesn't crash.
I get perhaps an unrelated error constantly logged which I think comes from the Sonos DOCK:

debug: [media] device/4 DOCK event=subscribe, state=end, code=405, err=null, headers={"allow":"GET, HEAD","content-type":"text/html","server":"Linux UPnP/1.0 Sonos/24.1-74200 (WD100)","connection":"close"}
error: [media] device/4 DOCK event=currentTrack, diagnostic=read ECONNRESET
error: [media] device/4 DOCK event=getVolume, diagnostic=read ECONNRESET
error: [media] device/4 DOCK event=getMuted, diagnostic=read ECONNRESET
warning: [discovery] device/4 DOCK event=subscribe, code=405, content=<HTML><HEAD><TITLE>Error 405</TITLE></HEAD><BODY><H1>Error 405</H1><P>Method Not Allowed</P></BODY></HTML>
debug: [media] device/4 DOCK event=subscribe, state=end, code=405, err=null, headers={"allow":"GET, HEAD","content-type":"text/html","server":"Linux UPnP/1.0 Sonos/24.1-74200 (WD100)","connection":"close"}
warning: [discovery] device/4 DOCK event=subscribe, code=405, content=<HTML><HEAD><TITLE>Error 405</TITLE></HEAD><BODY><H1>Error 405</H1><P>Method Not Allowed</P></BODY></HTML>
debug: [media] device/4 DOCK event=subscribe, state=end, code=405, err=null, headers={"allow":"GET, HEAD","content-type":"text/html","server":"Linux UPnP/1.0 Sonos/24.1-74200 (WD100)","connection":"close"}
warning: [discovery] device/4 DOCK event=subscribe, code=405, content=<HTML><HEAD><TITLE>Error 405</TITLE></HEAD><BODY><H1>Error 405</H1><P>Method Not Allowed</P></BODY></HTML>
debug: [media] device/4 DOCK event=subscribe, state=end, code=405, err=null, headers={"allow":"GET, HEAD","content-type":"text/html","server":"Linux UPnP/1.0 Sonos/24.1-74200 (WD100)","connection":"close"}
warning: [discovery] device/4 DOCK event=subscribe, code=405, content=<HTML><HEAD><TITLE>Error 405</TITLE></HEAD><BODY><H1>Error 405</H1><P>Method Not Allowed</P></BODY></HTML>
debug: [media] device/4 DOCK event=subscribe, state=end, code=405, err=null, headers={"allow":"GET, HEAD","content-type":"text/html","server":"Linux UPnP/1.0 Sonos/24.1-74200 (WD100)","connection":"close"}
warning: [discovery] device/4 DOCK event=subscribe, code=405, content=<HTML><HEAD><TITLE>Error 405</TITLE></HEAD><BODY><H1>Error 405</H1><P>Method Not Allowed</P></BODY></HTML>
debug: [media] device/4 DOCK event=subscribe, state=end, code=405, err=null, headers={"allow":"GET, HEAD","content-type":"text/html","server":"Linux UPnP/1.0 Sonos/24.1-74200 (WD100)","connection":"close"}

[mrose17]

thanks. i'll figure out what's going on in the lifx code. it looks like the node-clone library is doing somehow making this happen.

can you mail the entire steward output to [email protected] … you shouldn't be seeing that, i've got a sonos here and it works great. thanks!

[mrose17]

actually, i think you have to remove only one file: lighting-lifx-bulb.js

[stormboy]

Yes, it runs when removing only the LIFX device file.

Do you have the Sonos Dock? http://www.sonos.com/shop/products/Dock
It isn't the same as a Zone player, but I am guessing the device code is treating it like a zone player.

I've emailed you a log.

[mrose17]

i got the log, thanks!

i have a play bar. i think you're right about the device code. i'm looking into it now...

[stormboy]

I just spent hours trying to communicate with my USB XBee interface. It worked fine standalone, but not in the Steward. I was OK adding a fingerprint so the USB device could be found. It's a FTDI USB device.

Eventually I found that one of the Insteon gateway device objects was opening the same serial port because, where it counts, it has the same FTDI device fingerprint. I removed both Insteon gateway files from the devices directory and finally it works.

Is there a way to stop serial devices from being opened or hogged if the fingerprints match, but the device turns out not appropriate?

[mrose17]

i'm very sorry to hear this: very frustrating. the solution: create a file called db/configuration.json:

    { "deviceTypes" :
      { "exclude"   : { "gateway"  : [ "insteon-automategreen", "insteon-9761" ] }
      }
    }

i'm pretty sure you only need the first insteon entry, but there's no harm in having both… this should prevent those files from loading.

also, what is the fingerprint that you're seeing?

i'm very sorry about wasting your time on this issue.

[stormboy]

I'll put it down to a learning experience. Thanks for the tip. I'm using the fingerprint:

{ vendor         : 'Sparkfun'
, modelName      : 'XBee Explorer USB'
, description    : 'USB to XBee wireless adapter ZB (ZigBee mesh)'
, manufacturer   : 'FTDI'
, vendorId       : 0x0403
, productId      : 0x6001
, pnpId          : 'usb-FTDI_FT232R_USB_UART_'
, deviceType     : '/device/gateway/zigbee/xstick2-zb'
}

Log shows:

info: [discovery] /dev/cu.usbserial-A4013FE3 manufacturer=FTDI, vendorID=0x0403, productID=0x6001, serialNo=A4013FE3

[stormboy]

I forgot to mention as part of the problem solving process I had to remove the lifx module too. It was using all the CPU and stopping things from functioning in a timely manner. Do you see this problem?

[mrose17]

thanks. i have one LIFX bulb (i made some mods to the driver, like the one a few days ago to get around the assertion fail), but i don't use them.

could i ask you to submit a new issue at https://github.com/TheThingSystem/steward/issues/new -- or, if the fix is "obvious", a PR would be great.

thanks!

ps i am on a road trip for the next few days, so my online status is a bit spotty.

[mrose17]

adding @aallan

i think that the solution here is to get rid of fingerprint scanning if the fingerprint looks generic, e.g., the one above, and instead let the user specify a /dev/XYZ value in the db/configuration.json file.

this means that the RFXCOM and zigbee xstick will still auto detect, but for everyone else (insteon, zwave, etc.), folks will have to edit a file. comments?

[mrose17]

hi. anything to discuss? just checking, thanks!