User Tools

Site Tools


supported_hardware:hubitat

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
supported_hardware:hubitat [2021/01/02 14:39] – created James Sentmansupported_hardware:hubitat [2023/11/04 13:49] (current) – [XTension Settings:] added more info about the static IP issue James Sentman
Line 1: Line 1:
 =====Hubitat===== =====Hubitat=====
 {{:supported_hardware:hubitat_hero.jpg?400 |}} {{:supported_hardware:hubitat_hero.jpg?400 |}}
-The [[https://hubitat.com/|Hubitat]] is a ZWave and ZigBee hub that can be connected to XTension via the new Hubitat plugin. This plugin is currently in beta and you should not convert your entire Z-Wave network to one as it is not feature complete as of this writing. It offers a choice for ZWave connectivity in XTension beyond the older Vera units that we will continue to support. As of this moment both the plugin as well as the support for local connectivity in the Hubitat itself are under construction and so features and functions may continue to be added or removed as the protocols develop. Note that currently the plugin is not as feature complete as the Vera plugin and given that I don't know what will get added to the Hubitat protocols or when it may never be. Switching between the 2 devices cannot yet be done as a simple conversion from one plugin to the other. See more info below+(v1.4.9) The [[https://hubitat.com/|Hubitat]] is a ZWave and ZigBee hub that can be connected to XTension via the new Hubitat plugin. It offers a choice for ZWave connectivity in XTension beyond the older Vera units that we will continue to support but that are no longer being producedThis is our best choice for ZWave support in XTension. These are very nice hubs with a good interface for XTension to use them as a ZWave interface.
  
  
 ====Hubitat Setup:==== ====Hubitat Setup:====
-Follow the standard initial Hubitat setup. A cloud connection is not required for XTension to talk to the Hubitat, all communications are done over the local network and so it is necessary that the Hubitat and the XTension be on the same local network subnet. If you have a more complex networking setup and need to specify the local address that it should tell the Hubitat to send push updates to please let me know and I can prioritize that to be added in a future plugin version.+Follow the standard initial Hubitat setup. A cloud connection is not required for XTension to talk to the Hubitat, all communications are done over the local network and so it is necessary that the Hubitat and the XTension be on the same local network subnet. Earlier Hubitat OS versions did not support the setting of static IP but more recent ones do. 
 + 
 + 
 +>**You should give the Hubitat a static IP address either via the built in network settings or via a reserved DHCP address on your router. The local network lookup of “hubitat.local” can be very slow and cause noticeable delays in all communication and control.**
  
 ===Install the MakerAPI Plugin on the Hubitat:=== ===Install the MakerAPI Plugin on the Hubitat:===
Line 24: Line 27:
 in this case the API ID is the "67" in the link and the Access Token is the long string of numbers and dashes at the end after the "access_token=" portion. Your API ID and access token will be different from the example above. Keep this page open as you will need to cut and paste those values into XTension in the next step. in this case the API ID is the "67" in the link and the Access Token is the long string of numbers and dashes at the end after the "access_token=" portion. Your API ID and access token will be different from the example above. Keep this page open as you will need to cut and paste those values into XTension in the next step.
  
 +----
 ====XTension Settings:==== ====XTension Settings:====
 {{:supported_hardware:hubitat_settings.png?600 |}} {{:supported_hardware:hubitat_settings.png?600 |}}
Line 30: Line 34:
 If you have only a single Hubitat on your network you can leave the defaults for **Address** as "hubitat.local" under normal circumstances the port should be left as "80." If you have only a single Hubitat on your network you can leave the defaults for **Address** as "hubitat.local" under normal circumstances the port should be left as "80."
  
-If you are running multiple Hubitat's on the network then you will need to provide them with Static IP addresses so you know which one XTension is connecting to. There is no interface to this inside the Hubitat itself so you will need to visit the configuration of your router and create a DHCP reservation for the 2 devices, then restart them to make sure they pick up the new address if you changed it from what they were using at the time. Then enter that into the address field+If you are running multiple Hubitat's on the network then you will need to provide them with Static IP addresses so you know which one XTension is connecting to.
  
-If you have setup local access security on the Hubitat check the "Send Authentication" checkbox and enter the user and password. **NOTE:** as of this beta version sending passwords is not implemented. If this is something you need sooner please let me know and I will move it up the list of items yet to implement. It will be available before the plugin is promoted out of beta.+**NOTE: there is a problem that causes very slow performance when using the hubitat.local address. Later version of the Hubitat firmware have implemented the ability to set a static IP address and I recommend that you do this rather than rely on the local mDNS address. Then place the IP address into the Address field rather than the “hubitat.local” default. If you can’t set this through the hubitat interface a DHCP reservation in your router will work as well.** 
 + 
 +If you have setup local access security on the Hubitat check the "Send Authentication" checkbox and enter the user and password.
  
 Enter the API ID and Access Token from the URL's in the MakerAPI setup screen into the next section. Enter the API ID and Access Token from the URL's in the MakerAPI setup screen into the next section.
 +
 +The **Scan For New Devices Now** button will be enabled if the plugin interface is running and will perform a deep database scan when you click it. If you add new devices to the MakerAPI sharing list you can make them show up in XTension immediately by clicking that button. A deep scan is run every 5 minutes, this button runs it on demand.
  
 Click the Save button to save the Hubitat plugin instance in XTension. You can then enable the plugin in the Interfaces list window. Click the Save button to save the Hubitat plugin instance in XTension. You can then enable the plugin in the Interfaces list window.
 +
 +----
 +
 +====Unit Naming Conventions:====
 +When XTension sees a new unit in the Hubitat it will automatically create a new unit for it with all the proper settings. It will also use the name you have given the unit in the Hubitat as it’s starting point. Once the unit is created the name of the unit is no longer important to the connection and you can change the name in XTension without changing it in the Hubitat. This can be useful if there are name length restrictions or if the naming convention you are using inside the hubitat would not be as useful as what you want to use in XTension.
 +
 +-----
  
 ====Using The Hubitat Plugin:==== ====Using The Hubitat Plugin:====
Line 68: Line 83:
  
  
-**Note:** as of this beta version there is not yet an "insert" toolbar menu item to insert default handler for these actionsThat will be added before the release.+**NOTE:** The default drivers in the hubitat may not support multi-clicks more than double clickIf you find a community driver that supports more that are not passed properly through to XTension please let me know and we can collect the information I need to properly support them.
  
-**NOTE:** Unlike the Vera it seems that the Hubitat only supports single and double clicks. Devices that support multiple clicks beyond that do not share that data with XTension yet. When this becomes available in the Hubitat API I will make sure it works properly with XTension.+**Device Notifications:** If the device supports a notification such as the flashing light on some switches and you define that in the Hubitat that notification will show up as a separate unit in XTension that will allow you to turn on and off the notification display by turning on and off the unit.
  
-====Things That Are Not Implemented Yet:==== +===Scene Controllers:=== 
-Multiple taps on a central scene switch beyond single and double tap are not sent by the Hubitat. If you make use of the triple or more click capability of some switches that is not currently workingThis is limitation in the Hubitat and so I cannot say when or if it will be addressed but since I use that functionality I will certainly be pushing for it from them. It does appear that the Hubitat itself supports more taps than just the double tap it is just a matter of them making this information available to the MakerAPI protocol and then I can support it as well.+As of XTension 9.4.41 scene controllers and other devices with buttons or inputs should again behave properlyWireless scene controllers will now create single unit in XTension. It will not change state itself, but it will receive central scene events about which button was pressed and the number of clicks as available. Hold and release are handled the same as the examples above for switches.
  
-Devices with more than the 2 buttons on a regular paddle switch do appear to be workingThe third "config" button on the Innovelli switches does come in as a tap on button 3(though no double tap is supported on it) So I expect that central scene controllers with multiple buttons will also work normally but I have not yet tested this. At least they should work normally for single and double taps, more than that are probably not supported yet given the above limitation.+----- 
 +====Controlling Status LEDs:==== 
 +As of XTension 9.4.41 you can now control the status LED’s of the Home Seer WD200+ dimmersPlease see the [[supported_modules:hs-wd200|article about the WD200]] for more info and code examples. 
 +-----
  
-Virtual units may not be controllable from XTension yet but they will send their value and state changes to XTension. I'm not sure yet why some appear to work normally and others do not but will get this sorted out for the release.+====Sending Device Specific commands:====
  
-Sensor type devices that should be controllablefor example door locks or garage door controllers may not be controllable yet from XTension. If you have a device like this that does not work properly please drop me a note and we can gather some data to help make this work properly.+Many devices may have special commands that are not part of a normal Unit control, or that are just not implemented in this plugin yet. If that is the case you can use the **sendDeviceCommand** This is the same command that is used in the article above on controlling the status display on WD200 and other dimmers. This command allows you to send any command that you know the device supports regardless of the state of it’s support in XTension. It does require that the command be supported in the MakerAPI and the driver that the Hubitat is using.
  
-As of this moment it does not appear that setting of device firmware data is supported by the Hubitat protocolSo things like setting the LED display colors on the Innovelli or Home Seer switches is not yet possibleI hope to either have this sorted out or to have a feature request in to the Hubitat folks to implement it as soon as possible but since it is up to them on their side I cannot guarantee when or if this will ever work properlyIt is something I make a lot of use through the Vera and so I will be pushing hard to find a way to make this work. It does appear that the hub itself supports setting this information. It is just a matter of bringing it out to the MakerAPI protocol so that we can do it remotely.+Specific examples below but the general syntax for use requires that you know the command you’re trying to sendThis can be found in the “Commands” portion of the Device control screen on the hubitatIt will have a big button for each command. If the command requires additional parameters then it will have fields for you to enter them. Those same parameters must be passed in the same order to the sendDeviceCommand command as additional parameters after the command name)
  
-The support for location events, control of modes and control of the "HSM" or security features of the Hubitat are completely untested as of this first beta. If you are using these things and they do not work as expected please drop me a note and we can collect some more data to make it easier for me to properly implement them on our side.+Since the Hubitat does not allow the low level setting of parameters in the device by number, you have to find the name of the command given to the parameter you wish to set by the driver as described anove.
  
-Since this is a new Hub and a new plugin and I have not built a large system with it yet there will almost certainly be other issues and limitations with specific devices and I cannot yet speak about those. Overall it appears the Hubitat has very good support for the more standard ZWave and ZigBee devices. Please visit their support community to verify that any other more exotic devices you might use are supported and working before you dive in+<code> 
 +tell xUnit “the name of the Unit” to sendDeviceCommand( “reboot”, ...(any number of additional path parameters needed by the command)) 
 +</code>
  
-The Hubitat and it'MakerAPI protocol are moving targets as of this moment, new firmware updates may break things, or fix things or add or remove features. I do not have control of that but will of course do everything I can to keep up with the latest upcoming changes. There may be frustrations ahead but by doing some integration of this device you will definitely help get it as reliable and feature complete as it is possible to be.+If you are running the command inside the Unit’on or off script then you can leave off the tell xUnit portion and just use the sendDeviceCommand() without it.
  
 +Here are a couple of examples of using the command for real world devices. If you find a command for a device not listed here please let me know and I’ll add it as an example.
 +
 +===HomeSeer Flex Sensor===
 +This device has the capability of producing a beep or alert sound. There is no standard Unit command to beep but you can use the sendDeviceCommand like this:
 +
 +<code>
 +tell xUnit “name of HomeSeer Flex Sensor” to sendDeviceCommand( “beep”)
 +</code>
 +
 +===Aeotec Home Energy Sensor===
 +This device has a command to reset the energy usage numbers which can be sent with the command:
 +
 +<code>
 +tell xUnit “name of Home Energy Monitor unit” to sendDeviceCommand( “resetMeterAccumulation”)
 +</code>
 +
 +
 +-----
 ====Converting from the Vera:==== ====Converting from the Vera:====
-I know there is great interest among some folks to have an alternative to the Vera for ZWave controlAs of this moment I do not recommend just transferring your entire network to the Hubitat. There is too much to do yet though if you were to begin transferring individual units, especially unusual or special ones that will help me to make sure all those are as well supported as possible given the evolving state of the Hubitat communications protocol+You cannot simply transfer your network from the Vera, or any other ZWave controller, and the HubitatThey do not even attempt to support the transfer of the master controller as there are still so many holes in the implementation of most devices. No secure devices would transfer at all anyway by design. So the conversion process can be lengthy if you have many devices.
  
-Indeed, even if you wanted to you cannot simply transfer the network from another controller to the Hubitat. This feature seems to be missing from their feature list and instead they recommend removing the devices from the old controller and adding them to the Hubitat one at a time. This would be a HUGE job for some folks with larger networks and so I hope they will relent and work on the bulk transfer as an important feature for people switching to their hub+I would recommend removing devices from the Vera a few at a time, then re-linking them with the hubitatIn the MakerAPI app settings you’ll need to then select them for sharing. After that they will show up in XTension and new units will be created. You can then move the scripts over to the new units, delete the old Vera units and make sure the names are now the same as they were so that any scripts that access them will continue to do so without errors.
  
-Please make your desire for this to them via feature requests or posts on their community support boards!+If you have the Units setup in any Views, events or web interfaces you will need to re-select them there too.
  
 +There is no reason to do an entire update at one time, except that you’ll be reducing the mesh qualities of the old network as you build up the new one. So I would do them in physical portions that might be routing through each other. This way the old device and the new devices will continue to be reachable on whichever interface they are connected to. XTension will happily control some through the vera and some through the Hubitat as you are converting.
  
 +You’ll find that it’s worth the effort as the Hubitat support, especially for things that were notoriously unreliable on the Vera such as door locks, work much better on the hubitat. They are sill in business as well and so their support continues to add new devices and improve the support of older devices. The way the interface to the hubitat allows you to write your own plugins, or cut and paste code fomr the community message boards on their site means that there is always going to be code available to support new devices, or less used features of special devices that aren’t supported by the built in drivers.
 +
 +-----
 +====Potential Issues:====
 +  * I cannot currently get my Hubitat to recognize some older ZWave 1 switches. They can be added only as a “Device” and are not controllable. Changing the device type in the Hubitat to a generic dimmer or switch does show the rest of the controls but they cannot be successfully controlled.
 +  * Some older switches do not keep their state updated in the Hubitat and will report an incorrect value some time after you control them. I have written code into the plugin to get around this which fixes most but not all of the problems. If you find you have Units that continue to show that they are still on or still off after some time after they were controlled you can create a script that just sends a query to that unit. That will update it to the proper value. And use the on and off script of the Unit to execute that script a few minutes after the Unit has changed state or value. This will result in it being correct, but only some time after it was wrong for a bit. This is good enough for me in every circumstance I’ve found so far. I am able to look through my inside lights list and find any that were actually left on as opposed to having several units always report that they are on when they were turned off and are actually off.
 +  * The enumerations for things like Thermostat Modes are different than the Vera. To avoid confusion you should script them via the newer [[dictionary:unitinformation:enumeratedvalue|Enumerated Value]] capabilities of XTension so that you can do things like:
 +<code AppleScript>
 +set value of “Thermostat Mode Unit” to “cool”
 +</code>
 +
 +
 +-----
 +====Gathering Data For Unsupported Devices:====
 +If you have a device that is either not showing up at all or it showing no updates or the wrong updates please do the following to capture info about it. First I need a full database dump from your hubitat and the name of the device or it’s address so I can find the pertinent data in the potentially large database info. Please visit this link on your Hubitat, filling in your Access Token as described above in the initial setup:
 +
 +<code>
 +http://hubitat.local/apps/api/<replace with your APP ID Number as above>/devices/*?access_token=<replace with your access token as above>
 +</code>
 +
 +That will download some pages of JSON data into your browser, you can cut and paste it into an email to me or save it to a file and email me that if the data is too large.
 +
 +Second I will need some of the push data that the hubitat sends when values change or are updated. In the Interface List window in XTension control click, or perform a contextual click on the hubitat interface you created there and select “Turn Debug Mode On” Now all the push information that is received will be written to the XTension log. Do whatever you need to in order to create some push updates from the Hubitat and then copy and paste those lines into an email to me as well. I’ll do whatever possible to support any devices that aren’t already handled properly.
 +
 +-----
 ====History:==== ====History:====
   * The Hubitat plugin was first added as a beta version in XTension v9.4.35 in January of 2021   * The Hubitat plugin was first added as a beta version in XTension v9.4.35 in January of 2021
 +  * Thermostats are working as of XTension version 9.4.36 plugin version 1.1 
 +  * Ceiling Fan control is working as of XTension version 9.4.37 plugin version 1.2 
 +  * Scene Controllers are working as of XTension 9.4.41 
 +  * Valve devices, and other more unusual enumerated devices, are working as of XTension 9.5.2
supported_hardware/hubitat.1609598376.txt.gz · Last modified: 2023/02/13 14:51 (external edit)