supported_hardware:hubitat
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
supported_hardware:hubitat [2023/04/07 15:42] – [Things That Are Not Implemented Yet:] removed things that are supported now James Sentman | supported_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===== | ||
{{: | {{: | ||
- | (v1.2) The [[https:// | + | (v1.4.9) The [[https:// |
====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. | + | 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. |
+ | |||
+ | |||
+ | > | ||
===Install the MakerAPI Plugin on the Hubitat:=== | ===Install the MakerAPI Plugin on the Hubitat:=== | ||
Line 31: | Line 34: | ||
If you have only a single Hubitat on your network you can leave the defaults for **Address** as " | If you have only a single Hubitat on your network you can leave the defaults for **Address** as " | ||
- | If you are running multiple Hubitat' | + | If you are running multiple Hubitat' |
- | **NOTE:** there is a bug somewhere either in their firmware or in the Mac implementation of the bonjour lookups | + | **NOTE: there is a problem |
- | If you have setup local access security on the Hubitat check the "Send Authentication" | + | If you have setup local access security on the Hubitat check the "Send Authentication" |
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. | ||
Line 47: | Line 50: | ||
====Unit Naming Conventions: | ====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. | 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 78: | Line 83: | ||
- | **NOTE:** The default drivers in the hubitat | + | **NOTE:** The default drivers in the hubitat |
**Device Notifications: | **Device Notifications: | ||
Line 85: | Line 90: | ||
As of XTension 9.4.41 scene controllers and other devices with buttons or inputs should again behave properly. Wireless scene controllers will now create a 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. | As of XTension 9.4.41 scene controllers and other devices with buttons or inputs should again behave properly. Wireless scene controllers will now create a 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. | ||
+ | ----- | ||
====Controlling Status LEDs:==== | ====Controlling Status LEDs:==== | ||
As of XTension 9.4.41 you can now control the status LED’s of the Home Seer WD200+ dimmers. Please see the [[supported_modules: | As of XTension 9.4.41 you can now control the status LED’s of the Home Seer WD200+ dimmers. Please see the [[supported_modules: | ||
+ | ----- | ||
- | ====Things That Are Not Implemented Yet:==== | + | ====Sending Device Specific commands:==== |
- | 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 working. This is a 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. | + | |
- | The Hubitat and it's MakerAPI protocol | + | 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 |
+ | Specific examples below but the general syntax for use requires that you know the command you’re trying to send. This can be found in the “Commands” portion of the Device control screen on the hubitat. It 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) | ||
+ | |||
+ | 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. | ||
+ | |||
+ | < | ||
+ | tell xUnit “the name of the Unit” to sendDeviceCommand( “reboot”, | ||
+ | </ | ||
+ | |||
+ | If you are running the command inside the Unit’s 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: | ||
+ | |||
+ | < | ||
+ | tell xUnit “name of HomeSeer Flex Sensor” to sendDeviceCommand( “beep”) | ||
+ | </ | ||
+ | |||
+ | ===Aeotec Home Energy Sensor=== | ||
+ | This device has a command to reset the energy usage numbers which can be sent with the command: | ||
+ | |||
+ | < | ||
+ | tell xUnit “name of Home Energy Monitor unit” to sendDeviceCommand( “resetMeterAccumulation”) | ||
+ | </ | ||
+ | |||
+ | |||
+ | ----- | ||
====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 control. As of this moment I do not recommend just transferring your entire network | + | You cannot simply transfer your network from the Vera, or any other ZWave controller, and the Hubitat. They do not even attempt |
+ | |||
+ | I would recommend removing devices from the Vera a few at a time, then re-linking them with the hubitat. In 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. | ||
+ | |||
+ | If you have the Units setup in any Views, events or web interfaces you will need to re-select them there too. | ||
- | 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 | + | There is no reason to do an entire update at one time, except that you’ll be reducing |
- | Please make your desire | + | You’ll find that it’s worth the effort as the Hubitat support, especially |
+ | ----- | ||
====Potential Issues:==== | ====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. | * 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. | ||
- | * As of this moment only click and double click and click and hold appear | + | * Some older switches do not keep their state updated in the Hubitat |
* The enumerations for things like Thermostat Modes are different than the Vera. To avoid confusion you should script them via the newer [[dictionary: | * The enumerations for things like Thermostat Modes are different than the Vera. To avoid confusion you should script them via the newer [[dictionary: | ||
<code AppleScript> | <code AppleScript> | ||
Line 110: | Line 148: | ||
+ | ----- | ||
====Gathering Data For Unsupported Devices: | ====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: | 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: | ||
Line 121: | Line 160: | ||
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. | 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 | ||
Line 126: | Line 166: | ||
* Ceiling Fan control is working as of XTension version 9.4.37 plugin version 1.2 | * 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 | * 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.1680882133.txt.gz · Last modified: 2023/04/07 15:42 by James Sentman