HSZigbee Now In Beta

[logman]

As for the event issue, that is my issue in HS and I will get that fixed.

Four months later and the issue has not been fixed yet. I'm not much of a programmer, but isn't this just a simple .NET Postback issue? What I do know is that when you go to setting up events with dozens of bulbs it's annoying to say the least.

[logman]

And while I'm in gripe mode, what's up with the new API not passing the white balance and saturation back to HS? No CT child device and no saturation child device. There should be 3 child devices but we're only getting 1. It also doesn't bring in the device friendly name nor any groups created in the Lightify app. So once you get all that work hand duplicated into HS you basically end up with an on/off button.

Zigbee is a great platform and is superior to Z-Wave for certain applications (lights and battery operated sensors, for example). Have you ever seen a "Repair Zigbee Network" button? Nope, because it's always analyzing the mesh network to find the most efficient route to the endpoint. Z-Wave can hop 4 times from the router and Zigbee can hop 40 times. When you put Zigbee lights in a group they each know the other group members and work in concert to turn on and off in perfect sync. Zigbee devices are also normally cheaper, I'm guessing probably because of lower licensing fees back to the Zigbee Alliance vs. Z-Wave Alliance (the basic hardware is practically the same).

It's a shame we have such a powerful platform with HS but such a sorry excuse for Zigbee integration. I know resources are limited and all that. But then you look at Hubitat, which probably consists of around a half-dozen guys, and they come out of the chute with a respectable Z-Wave and Zigbee hub. Coming from the SmartThings world they realize the importance of having each.

Well, that's enough rant. It's not my company and none of my business on how it's managed (or not managed). As a customer I either choose to do business with HS or I don't. Fair enough.

--Barry

[Mountainman]

It would be great if Zigbee got as much HS development as Z-Wave. I was sorely disappointed when Z-Wave came out many years ago and they re-invented the wheel with a proprietary protocol. Their wheel didn't turn out to be round and they have been trying to fix it ever since. I have been satisfied with control of Z-Wave devices from HomeSeer, but the reporting of status simply isn't reliable with the original Z-Wave spec (even with a direct hop).

Zigbee uses an IEEE protocol that appears to work (have not used it myself). It seems poised for success from a technical standpoint. Success or failure will probably come down to interoperability at the software level with Amazon and Google voice stuff since that is where the mass market is headed.

[Timon]

If Zigbee is solid it would be nice see a ZigBee version of the 200 series devices with the RGB status.

[Mountainman]

ZigBee versions of the HomeSeer switches would be enticing. I'm sure the ZigBee plug-in would need custom software to make it work with each device, but that is no different than what is happening now with Z-Wave devices. HST seems to be spending lots of time tweaking the Z-Wave plug-in for all the device nuances. If you are going to spend time doing custom software, you might as well use a protocol that works.

I'd like to hear more from users of the current ZigBee plug-in as to how reliable their setup has been.

[logman]

I'd like to hear more from users of the current ZigBee plug-in as to how reliable their setup has been.

I'm curious too, is anybody successfully using this plugin to manage more than 2 or 3 lights? Anybody? And if so, are they white lights or RGBW lights? I spent 2 days testing it trying to get it to control 10 RGBW lights and gave up.

For me this plugin is a joke and an embarrassment for Homeseer. It's a resource hog, stops responding every few hours and must be restarted. It's painfully slow waiting for lights to respond to commands and it ignores color settings. And by the way, none of that is related to the hub because it works super fast and flawless with the Lightify app.

Homeseer touting this as their Zigbee integration would be like a city putting 3 bicycles out on the sidewalk and saying they offer municipal transportation services.

[simplextech]

Homeseer touting this as their Zigbee integration would be like a city putting 3 bicycles out on the sidewalk and saying they offer municipal transportation services.

Do you live near me???

[logman]

Do you live near me???

Ha! No, but similar sized towns. (I had a driver stranded at the Inwood Flying J with a mechanical breakdown a few years ago.) At least you guys have an interstate. Our little hick town is definitely off the beaten path. But it is home to Bocephus, Merle Kilgore (RIP) and part-time resident Kid Rock.... Party!!!

[simplextech]

Ha! No, but similar sized towns. (I had a driver stranded at the Inwood Flying J with a mechanical breakdown a few years ago.) At least you guys have an interstate. Our little hick town is definitely off the beaten path. But it is home to Bocephus, Merle Kilgore (RIP) and part-time resident Kid Rock.... Party!!!

Sounds like a nice quiet area unless the Kid is in town

[logman]

Hey fuzzysb,

I've been working with this today to get Zigbee to Homeseer functioning for a few NYCE sensors. Worked great on the first device, but I hit a wall on getting the second device to report back to Homeseer. Looking at your device handler code (and thanks for providing this!), I noticed this at the bottom:

}

def ipSetup() {
    log.debug "In IPSetup Area"
    def hosthex
    def porthex
    if (settings.ip) {
        hosthex = convertIPtoHex(settings.ip).toUpperCase()
    }
    if (settings.port) {
        porthex = convertPortToHex(settings.port).toUpperCase()
    }
    if (settings.ip && settings.port) {
        log.debug "updating Network ID to ${hosthex}:${porthex}"
        device.deviceNetworkId = "${hosthex}:${porthex}"
    }
}

private String convertIPtoHex(ip) { 
    String hexip = ip.tokenize( '.' ).collect {  String.format( '%02x', it.toInteger() ) }.join()
    return hexip
}
private String convertPortToHex(port) {
    String hexport = port.toString().format( '%04x', port.toInteger() )
    return hexport
}

That converts the destination IP and port (of the host HS3 machine) to hex and then uses the result to update the Device Network ID of the virtual device created in SmartThings. I'm assuming the ST API requires the local LAN IP:PORT address to be converted to hex value for some reason and looks to the NetworkID for the result.

The problem is that SmartThings requires the NetworkID to be unique to each device. So when you try to add a second device the Network ID will not get updated because it would be a duplicate. In return the API never sends the command to HS3 because it doesn't have an address to send to.

Any ideas or know of a workaround?

--Barry

ok if anyone is interested and i apologise hijacking the thread a bit. i have uploaded my Smartthings connectivity code to github.

first add the following device handler available here to smartthings.

then create a new device and select this device handler. in the device settings specify the internal IP address of your homeseer server and the web port.

next add all the 5 smartapps available here

at the moment you can send Contact/Motion/Presence & Switch Statuses to Homeseer devices.

so to do this create a new device in homeseer and for Status ensure that the homeseer device has these values

Switch
0 = Off
100 = On

Contact & Motion
0=Closed/NoMotion
1=Open/Motion

Presence
0=Away
1=Home

Then take note of the Homeseer Reference Id

then just go into the smartthings app for example and install an instance of the Contact Sensor to HS3 App and select the Contact sensor which you want to send the status of, select the Homeseer HS3 device and specify the Homeseer Device ID.

then just open/close the sensor and you will see that the status of the virtual device is updated.

The Homeseer device handler can be updated to subscribe to more types etc.. quite easily. then you just need a smartapp to initiate the send of the status.

and lastly i have another which will synchronize the switch state between HS3 virtual device and ST, so you can turn on the switch on either platform and the status will be reflected in another.

much the same as the other smartapps however you need to enable oAuth in the smartapp settings. then find the app id and token from the smartapp settings once you have installed it and selected the switch device and specified the HS3 Device Id.

then i create an event in Homeseer where i specify if the homeseer device switch changes off i then run a script or script command and specify and select to execute an immediate script command the following

&hs.URLAction("https://graph-eu01-euwest1.api.smartthings.com/api/smartapps/installations/<AppID>/ST/off?access_token=<Access Token>", "GET", "", "")

and then i create one that triggers when the device turns on and specify

&hs.URLAction("https://graph-eu01-euwest1.api.smartthings.com/api/smartapps/installations/<AppID>/ST/on?access_token=<Access Token>", "GET", "", "")

then you will see that the switch status is kept in sync between HS3 and Smartthings

as stated though the solution is very clunky but i had it all up and running in one afternoon and it worked so well i didn't bother improving/expanding on it as i only used it during the migration to Homeseer.

I have also ported it to Hubitat and i use these purely for my Zigbee contact sensors/motion sensors and switches. again clunky to set up but works very well.

hope it helps you guys.

[fuzzysb]

logman I don't understand why you need another device with the same dni? You only have one HS3 api device. Any virtual switches etc don't need the same dni, you can give them anything. I usually put in the same as the device name.

It's only the HS3 device that needs the hex IPort combo

[logman]

Yep, I'm a dummy. I somehow had in my mind that you needed a HS3 virtual device in ST for EACH sensor. But nope. The one HS3 virtual device does the routing for multiple ST devices. You just deploy a new instance of the appropriate app for each sensor you want to monitor. I got it now, and it works!

This is an awesome solution for Zigbee sensors (motion, contact, leak detectors, switches, etc.). Actually HS could probably spend a little time working on this and have it import all your devices in from ST and take care of the scripting in the background to update ST devices with HS3 changes. Or somebody could develop a plugin without too much effort to do the same thing.

Thanks again!

--Barry

[Michael McSharry]

Is this still a could-based solution via the OSRAM gateway?

[logman]

Is this still a could-based solution via the OSRAM gateway?

Yes, the HS plugin is still cloud-based via Osram API... But I wouldn't call it a solution.

[Michael McSharry]

A low cost non-cloud solution is at https://forums.homeseer.com/forum/li...ailable-for-10