XBEE API/Communication/device support?

[pounce]

Hello,

 

I'm investigating various solutions for building automation. I would like to use Insteon devices so your product looks good for that. It would also appear that you are adding support for a Zigbee radio. This is good for me because I have custom sensors that use XBEE Pro S2 radios. I haven't been through all the wiki and documentation yet so forgive me. With the newer device from UD with Zigbee will I have the ability to integrate maybe 50 XBEE Pro S2 sensors? Is there an API/extension or software to allow this sort of integration?

 

What is supported and perhaps on the roadmap if not supported currently?

 

Thanks!

[Michel Kohanim]

Hi pounce,

 

ISY is extremely strongly typed device and framework. Although 994i Z supports Zigbee PRO, however, it has to know what it's communicating with. So, for instance, ISY994iZ supports RCS thermostats as well as Brultech energy monitors both of which are based on XBee.

 

994iZ Pro can support up to 64 Zigbee nodes.

 

So, in short, we would need the APIs/Specs for your sensors. We'll then do a sizing and based on ROI assign development priority.

 

With kind regards,

Michel

[pounce]

Thanks for the information.

 

Is there an opportunity for contributions or working on a more generic driver/protocol/message format?

 

I have the ability to program my sensors to send or respond with whatever I like. In this way if you have something you already prefer to work with perhaps we can find a quick and simple solution for adapting new devices.

 

Or could there a documented/existing interface I can leverage/copy so that no work is required on your side?

 

Thanks!

[Michel Kohanim]

Hello pounce,

 

It's not really APIs. ISY has to know what type of device it's communicating with and its capabilities. For instance, is it a sensor, what are the ranges, how many sensors, what type of a sensor, can it be configured? What can we do to it? Can we turn it on/off/dim? Without this information, it would be very difficult to have programs respond to events from these sensors.

 

Things that are important are Profile/Cluster IDs and commands.

 

As such, it would be impossible to reuse existing code without forcing ISY to consider those devices as thermostats or energy monitors.

 

With kind regards,

Michel

[pounce]

Thanks. I understand.

 

Would you have documentation or a sample for a thermostat?

 

Just sort of thinking out loud as it were...since you now have the ability to use zigbee and these radios are available to the masses have you considered that sensor manufacturers, open groups and the arduino/pic crowd might be leveraged and embraced to do really cool things within this space?

 

Perhaps the community can help develop an extensible message/logic aspect of your system. I can think of quite a few cool things that might help sell more of your product.

 

I can start a list.

[Michel Kohanim]

Hi pounce,

 

I am all for it. Having a generic messaging system to discover Zigbee devices, their capabilities, and types is quite powerful.

 

The only nagging problem will be that we will be implementing things that are already in HA or BA profile. i.e. we'll be competing with those profiles.

 

What are the advantages of having our own communications protocol vs. using those already offered through Zigbee Profiles?

 

With kind regards,

Michel

[pounce]

Are you implementing the mentioned profiles? Doing so would certainly be an ideal starting point. I would not disagree. I'd put that ahead of any generic extensible approach that didn't also solve the needs of devices that were supported by those profiles.

 

The Synapse radios also look pretty cool. I just stumbled on them researching this topic. The interop with xbee and easy python scripting could be interesting for you also. You are probably very aware of their stuff, but its new to me. Sort of wish I found it earlier, but I don't like using a "cloud" no matter how fluffy and bunny looking it might get. I also want and need more flexibility.

 

I guess we can clarify our nomenclature to make it easier to discuss the easiest path to solve customer needs and therefore sell more product over time.

 

I will also try to read more about how you support your device scripting and how a person can query other devices and data and then apply logic. Perhaps there are other ways to skin this cat...

[Michel Kohanim]

Hi pounce,

 

Thank you. We already support SEP (Smart Energy Profile) in our 99r4i ZS series. Currently, we have no plans for supporting HA profile mostly because there's no demand, a dearth of interopertable devices, and the fact that HA has some constraints (such as polling intervals) which does not work well for commercial venues.

 

This said, it all depends on what we are trying to achieve. If the goal is to support generic sensor/actuators, then HA is not a good fit and having an application layer with well defined events/commands is much cleaner. On the other hand, if the goal is to use existing HA devices, then we should pursue standard Zigbee profiles.

 

I have heard of both companies but, just like you, I do not like us to be tied to the cloud of any sorts. ISY must remain autonomous.

 

With kind regards,

Michel

[pounce]

Looks like it's possible to extend the HA profile. Perhaps an option would be to take a look at implementing the HA profile to support a larger group of existing products looking for your autonomous cloud independent brain and then look at extending the profile with creative ways to support generic or dynamic devices to support custom and customer specific needs.

 

Having this radio support looks like it can really open some new doors. I'm very interested to see where it goes.

[Michel Kohanim]

Hi pounce,

 

Thanks so very much for your thoughts. Now, it's time to generate some demand so that we can measure ROI for this solution!

 

Do you know of any others who might be interested?

 

With kind regards,

Michel

[pounce]

I noticed that the new Lowes Iris system is using some Zigbee devices. Having brick and mortar locations selling consumer zigbee products could be a good opportunity. Might be a chicken and egg thing. You might stimulate demand if you had controller that supported a wide array of existing consumer products. Someone that gets an Iris system might be unhappy with its options and lack of support for some of the Insteon products they want to use and then switch to your products.

 

I can't deny that it's exciting to see the Lowes Iris display at the front end cap at the entrance of each Lowes I've been in over the last few weeks. They are cobbling together parts from multiple companies and supporting zwave and zigbee. The larger the market that gets created the better for everyone. Competition is good here. I feel that there is plenty of room for products like yours to mingle with this larger players if you can support the devices. Quite honestly I would throw down $500 - 1k today if there was a robust system that would allow me to buy any controller, sensor, keypad etc from Insteon, zigbee or zwave.

 

FWIW: I'm a software and tools architect that specializes in the quality and performance aspects of enterprise and some consumer products and services. None of them in the HA space. It does look like there are a lot of cool testing tools and simulators for zigbee networks that could make QA quite a bit easier on a company. Not sure what they cost.

[Michel Kohanim]

Hi pounce,

 

I didn't realize Iris is using Zigbee ... as far as I remember, they only supported ZWave and WiFi devices.

 

So, are you specifically looking for Zigbee devices? Does the protocol really matter to you? If so, in what aspects?

 

With kind regards,

Michel

[Brian H]

Iris seems to be a unconventional system.

There are some Zigbee devices in the mix. From what I have seen on their support pages.

[kevinvw]

hmmm.. thought I replied to this topic... I see its kind of an old thread.... at any rate, I too am interested in some level of support for xbee modules.  I would not be that demanding though.  I could use a feature similar to your tcp client feature in the networking module.  for this case, I would like to pre-fill out a message packet form with the minumum required from/to/pan/... parameters, and a message body.  Send only would get me a long ways and it would only be from a program command.  That would allow me to perform some controls on my devices.  Not sure if there is much demand for this first level of generic support, hope so. 

As it is, I plan to use tcp to connect to a wifi intermediate controller and have that node repeat out a xbee message.  would be great to eliminate that middle man.

 

thanks

[Michel Kohanim]

Hi kevinvw,

 

The main issue is profile ids, cluster ids, and end points that are different between Zigbee modules. So, it's really not as simple as sending a TCP packet.

 

With kind regards,

Michel