Flair Puck and Vent integration

[Michel]

Hi Michael,

On top of gaining Zigbee access with the Hubitat I wanted to integrate some Flair smart components. A basic set consist of a room temperature sensor (Puck) combined with one or more motorized damper (Vent). I just received my first kit. These work using Wi-Fi and their proprietary protocol but one of the HE community member developed some Driver and Apps code connecting to their API.

From there, Maker API exposes a substantial quantity of Attributes and Commands since it includes about all of their internal variables used now with some that I thinks are for future evolution. And I do mean a lot. From all those, only a handful are really needed from what my very recent experience tells me. Your plugin intercepts a few of them and even fewer are usable or relevant. Here's what is being picked-up right now :



What I did is trim and parsed the relevant information from the plugin log and listed them in an excel sheet (now in PDF due to upload limitation). The yellow one are the one that would make sense having as read only info while the green one are some that can be also written like set-points and damper opening %. I'm also including the untouched log as reference.

Hoping that this is something you would feel up to.

Best regards

[Michael McSharry]

See where we are with the four new devices. You will want to remove the devices created yesterday so they can be newly created with this version. HS4 does not allow controls on root devices so I added another refresh device for control-only.

[Michel]

Man...you're a machine.

Observation :
Just notice this AM, before getting the previous post, that since 3.4.1.0 beta iteration 15, "commands" from HS to HE don't go thru. This is what the log shows but I'm not sure it is really giving the answer all other entries look as usual :

08/03/2021 06:42:08 11568 | SetIOMulti triggered, checking CAPI '(value) C' on device 1330 controlValue 20
08/03/2021 06:42:08 11572 | http://###IP###/apps/api/1/devices/2...20?###Token###

Food for taught :
Related to my other topic about the HEM Gen 5, I realized that some of the values are accumulator that one may want to reset let's say when a new day begin. As with the "refresh" above that could be a new device with the HE related command. "resetMeterAccumulation" in this case. But, as you know, there are tons of possible commands in HE that will keep on growing. Do you really want to expose them all. No of course, Flair being a good example of why (see image). But one command may be needed for a specific need by a specific user, translating in as much changes requests on your end. From there I was wondering if it would be a good idea to add a "Hubitat : Send command" in the "Event - Action" section.

The structure could be quite simple with (1) Device (Root) and (2) parameters (Fields) : "Command :" and "Value :". Of course it becomes the user responsibility to have the correct syntax and value type. Both are easily available in HE (see image again). Since many commands are requests or single action, if the 2nd field is null then it does not get send to HE. I don't have a lot of HE devices yet but if some commands can or need more then (1) value, they could be comma separated in the Event value field.

In my example it would look like :

Event:
IF "Time is 12:00:01"
THEN (Hubitat : Command) Device : Energy meter (Root)
Command : resetMeterAccumulation
Value : null

Other example with Flair. let's say one need to include this in his logic

Event:
IF "Some condition"
THEN (Hubitat : Command) Device : My Flair Puck (Root)
Command : setRoomTempAwayMin
Value : 65

As I'm writing, I realize that some commands would be returning data not related to created devices. Not sure how that would translate nor could be handled back to the user. I'm seeing "getZonesList" for a Flair vent. Not sure yet of what it is, what it would return etc...

Let me know what you think.

Thanks

[Michael McSharry]

I understand about the Event Action to send command. Once the step is taken to make the user responsible for command syntax then the HS built-in function getURL can be used for the Event Action. It would show up in the Event Action as a one-line script &hs.GetURL("HubitatIP","HubitatCommandSyntax",TRUE,80)

The debug and the console contain the command that the plugin is sending. Replace the ### info with the actual IP and the actual MakerAPI token and then you can use a browser with that URL to manually send the command. The command can also be inspected to confirm that it looks correct based upon what Hubitat discloses for "command" text.

Another thing to evaluate is the suffix I put on the devices such Amps, Kwh etc.

The most complex logic within the plugin is trying to deal with the general case Capability and then with the specific-case variants. For example, "level" is a volume control for some devices, brightness in others, and in this case a vent. "level" can have a different range depending upon the device. "pressure" can be kPA or inHg. When MakerAPI discloses a "Sensor" capability it does not help much for the plugin as there are so many different type of sensors.

[Michel]

I understand about the Event Action to send command. Once the step is taken to make the user responsible for command syntax then the HS built-in function getURL can be used for the Event Action. It would show up in the Event Action as a one-line script &hs.GetURL("HubitatIP","HubitatCommandSyntax",TRUE,80 )

I get your point. As basic as it might sound, I was not aware of this function and had totally zapped the related syntax information in the Maker API settings. Thanks for pointing me in the right direction.

The debug and the console contain the command that the plugin is sending. Replace the ### info with the actual IP and the actual MakerAPI token and then you can use a browser with that URL to manually send the command. The command can also be inspected to confirm that it looks correct based upon what Hubitat discloses for "command" text.

This is what I kind of made out of the #### usage and this is why I taught there was not much to help investigate the problem but for real, since iteration 15, values changed in HS don't make it to HE. If I change a set-point in HS, HS device take the new value but HE does not change.

If if enter this in a browser the value changes in HE :
http://###MY IP###/apps/api/1/devices/4/setHeatingSetpoint/20?access_token=###My Token###

If I change the value in HS, the log will show:
08/03/2021 16:21:15 86362 | http://###IP###/apps/api/1/devices/4...20?###Token###

But the value in HE does not change. So could it be a typo when the plugin is pulling the IP or Token from config?

Note I've upgraded to HS4...but kept HS3 version of your plug-in, since we already had something going. I'll change it to mcsHubitat once changes get ported to HS4.

Michel

[Michael McSharry]

According to the debug disclosure for "name":"Sinope TH1124ZB (4KW) Thermostat" the command that it expects is {"command":"setHeatingSetpoint"}

On my computer this would be like http://192.168.0.111/apps/api/device...f-73193c62fgdc

The devices/4/ indicates the hub id is 4. Mine is 1.

On Hubitat Devices page you will have a panel labeled setHeatingSetpoint and a text box below it. If you enter 20 in the text box and click the panel then it should send the value to the thermostat to confirm that part of the chain is working.

[Michel]

I might be wrong but from what I see the number before /devices is the hub number while the number after is the device id. so "1/devices/4" means hub 1 device 4.

Is it possible that the "access_token=" is missing in the recent revision. Same for your example below.

"192.168.0.111/apps/api/devices/4/setHeatingSetpoint/20?a36552b9-bacc-5cb3-b25f-73193c62fgdc"

If I do it from the HE device page, it is working and it was working in 3.3.14.1. I'll try re-inserting this version tomorrow AM.

This is working on my end:

"http://192.168.1.63/apps/api/1/devices/4/setHeatingSetpoint/20?access_token=0ecb01d8-75ca-4b30-b477-9964bc3e3934"

[Michael McSharry]

You are correct. MakerId is follows /api/ and DeviceId follows /devices/
You are also correct about the token prefix access_token=

I see the message board hides the URL so need to copy and paste elsewhere to see the intent.

http://192.168.0.111/apps/api/1/devices/4/setHeatingSetpoint/20?access_token=a36552b9-bacc-5cb3-b25f-73193c62fgdc

What is different between the browser URL and the debug URL? i.e. why is it not working from the plugin?

[Michel]

Michael,

Did some more testing this morning. I was wrong by saying that the "bug" appeared between Zip (15) and Zip (16) as Zip (15) does not send commands either. Here's what I did, in HS4 but still using HS3 plugin for the moment :

• Removed all Hubitat plug-in, files, folder, plugin from HS. Fresh start.
• Installed released version 3.3.14.1 many devices missing but I was able to send command.
• Replaced HSPI file by the one in Beta Zip (16) that includes support for additional devices. All scanned good BUT unable to send commands anymore.
• Replaced HSPI file by the one in Beta Zip (15) and the problem stayed.
• Reintroduce HSPI 3.3.14.1 file and all commands are now sending.

May I suggest that you make full disclosure of the http sent command in the log as the masked ### information may be hiding a typo in the syntax that we cannot see right now. The portion that has not been masked looks OK but of course, this is not what is being sent. Beside that, I suppose that only you can tell what has been touched and changed between Released 3.3.14.1 and Beta 3.4.1.0

Let me know if you want me to test something else.

[Michael McSharry]

For my testing I am using a bulb that has nine controllable features in HS and it is responding as expected with HS4 and the mcsHubitat HS3 plugin. The non-redacted URL is displayed in the console. The console is enabled from HS4 Settings Developer Mode checkbox.

As I test back and forth between the HS3 and HS4 plugin a different set of HS4 devices are often created when sync with Hubitat. Make certain the devices that you are trying to control are the ones sync'd with Hubitat. The plugin Config page shows the set of devices and the HS device name/ref. The console also display message about not being in device map if the wrong device is being controlled. It will also be in the debug. (\data\hubitat\hubitat_debug.txt). This is the file that has useful information to help with debug.

I did download the .exe you posted and it worked fine to control my bulb. Generally there is no value in posting back the .exe file.

[Michel]

Agreed that uploading .exe does not serves much. Sorry about that. I was simply trying to make the breaking point as clear as possible since we're dealing with different iteration of 3.4.1.0

Thanks for orienting me to the Developer mode. I had seen and tried that check box but did not see the purpose. Now, I realize that you need to restart HS and the Console windows will appear on the PC running HS. Remote Desktop only in my case.

With the "non-working for me" HSPI the http generated is the same as the "working" version and if copied and paste to the web browser, it works.

I've loaded a few time each of the HSPI and one thing is consistently the same in the Console window. The Working version has a "HubistatStart" statement that does not appear in the other (2) "non-working for me" versions. See below attached.

For clarity again this is in HS4, running the HS3 version.

Question : Have you ported the recent changes to mscHubitat? If so, I'll install and focus on that version.

[Michael McSharry]

Have you ported the recent changes to mscHubitat? If so, I'll install and focus on that version.

Not yet. I will do it this evening.

Does the debug file contain the communications with hubitat? At the start should be the response that declares everything routed through MakerAPI. If it is not receiving anything then it would also not recognize commands. It could be a different version of a .NET dll that may be hiding somehting.

[Michel]

See attached. I suppose you are referring to large chunk starting on line 2.

According to the W10 Registry my NET Framework setup would be 4.8.0.4.084 but I'm having difficulties locating in what folder these dll would be.

[Michel]

What does "HubistatStart" stands for? Is this an instruction sent by the plugin or received from Hubitat?

[Michael McSharry]

It is just a marker that a specific piece of code was executed. It may have been removed as not having value added with subsequent messages providing the equivalent information. In this case HubitatStart was just a wrapper around HubitatIO so was removed.