Node-RED nodes for hubitat

Question regarding communication from HE to NR using the maker API. I am seeing a few things that stand in the way of what I would like to do. I am looking to make sure I understand where they would need to be addressed if they became a priority to that party. (I am not suggesting they should be, just trying to clarify.)

The situation I am trying to address is being able to distinguish between physical and digital switching to on of switch. And to be able to see that the physical switch was turned on even if the state is already on.

I am using the Generic Z-Wave Smart Switch driver and Maker API tied to NR in the standard way.

For the digital versus physical, I am seeing this in the log for the switch:

[dev:33](http://192.168.86.110/logs#dev33)2020-04-07 12:40:49.714 pm [info](http://192.168.86.110/device/edit/33)Master Light Overhead was turned off [physical]
[dev:33](http://192.168.86.110/logs#dev33)2020-04-07 12:40:48.616 pm [info](http://192.168.86.110/device/edit/33)Master Light Overhead was turned on [physical]
[dev:33](http://192.168.86.110/logs#dev33)2020-04-07 12:40:13.388 pm [info](http://192.168.86.110/device/edit/33)Master Light Overhead was turned off [digital]
[dev:33](http://192.168.86.110/logs#dev33)2020-04-07 12:40:11.725 pm [info](http://192.168.86.110/device/edit/33)Master Light Overhead was turned on [digital]

In the log for the maker API, I am seeing:

[app:674](http://192.168.86.110/logs#app674)2020-04-07 12:40:49.781 pm [debug](http://192.168.86.110/installedapp/configure/674)device event: {"name":"switch","value":"off","displayName":"Master Light Overhead","deviceId":"33","descriptionText":"Master Light Overhead was turned off [physical]","unit":null,"data":null}
[app:674](http://192.168.86.110/logs#app674)2020-04-07 12:40:48.676 pm [debug](http://192.168.86.110/installedapp/configure/674)device event: {"name":"switch","value":"on","displayName":"Master Light Overhead","deviceId":"33","descriptionText":"Master Light Overhead was turned on [physical]","unit":null,"data":null}
[app:674](http://192.168.86.110/logs#app674)2020-04-07 12:40:13.537 pm [debug](http://192.168.86.110/installedapp/configure/674)device event: {"name":"switch","value":"off","displayName":"Master Light Overhead","deviceId":"33","descriptionText":"Master Light Overhead was turned off [digital]","unit":null,"data":null}
[app:674](http://192.168.86.110/logs#app674)2020-04-07 12:40:11.836 pm [debug](http://192.168.86.110/installedapp/configure/674)device event: {"name":"switch","value":"on","displayName":"Master Light Overhead","deviceId":"33","descriptionText":"Master Light Overhead was turned on [digital]","unit":null,"data":null}

In the debug log in NR, I am seeing:

4/7/2020, 12:42:15 PMnode: 38b47f05.288b9
Master Light Overhead : msg.payload : Object
object
name: "switch"
currentValue: "on"
dataType: "ENUM"
values: array[2]
0: "on"
1: "off"
value: "on"
deviceId: "33"

4/7/2020, 12:42:18 PMnode: 38b47f05.288b9
Master Light Overhead : msg.payload : Object
object
name: "switch"
currentValue: "off"
dataType: "ENUM"
values: array[2]
value: "off"
deviceId: "33"

4/7/2020, 12:42:47 PMnode: 38b47f05.288b9
Master Light Overhead : msg : Object
object
payload: object
name: "switch"
currentValue: "on"
dataType: "ENUM"
values: array[2]
0: "on"
1: "off"
value: "on"
deviceId: "33"
topic: "Master Light Overhead"
_msgid: "7ad4d8bb.7890a8"

So, does this mean that despite logging physical vs. digital that the maker API is not sending it to the NR node or does this mean that it is sending it, but the current iteration is not capturing that information into the node's output?

Second question, regarding physical after digital in a redundant manner. In the switches log, I see this:

[dev:33](http://192.168.86.110/logs#dev33)2020-04-07 01:05:06.315 pm [info](http://192.168.86.110/device/edit/33)Master Light Overhead was turned off [digital]
[dev:33](http://192.168.86.110/logs#dev33)2020-04-07 01:03:44.217 pm [info](http://192.168.86.110/device/edit/33)Master Light Overhead is on [physical]
[dev:33](http://192.168.86.110/logs#dev33)2020-04-07 01:03:21.870 pm [info](http://192.168.86.110/device/edit/33)Master Light Overhead was turned on [digital]

While the Maker API log shows:

4/7/2020, 1:03:22 PMnode: 38b47f05.288b9
Master Light Overhead : msg : Object
object
payload: object
name: "switch"
currentValue: "on"
dataType: "ENUM"
values: array[2]
value: "on"
deviceId: "33"
topic: "Master Light Overhead"
_msgid: "b64a567b.1ee7c8"

4/7/2020, 1:05:06 PMnode: 38b47f05.288b9
Master Light Overhead : msg : Object
object
payload: object
name: "switch"
currentValue: "off"
dataType: "ENUM"
values: array[2]
value: "off"
deviceId: "33"
topic: "Master Light Overhead"
_msgid: "3461d18f.73d31e"

This just points out that the Maker API seems to be ignoring the redundant on (physical) and never sends it to NR.

  1. Is that the right interpretation of that output?
  2. If so, is that because of anything I can choose in the Maker API to allow this to be passed?
  3. If it isn't a configuration choice, then I would have to ask for a change to the Maker API?

Finally, If I understand all of this correctly and these things are unlikely to be changed very rapidly, because the world doesn't revolve around me, is there any reason I couldn't build my own special purpose version of the maker API and the NR hubitat node to care for my particular desire to both pass physical vs digital and to pass redundant commands like the sequence I showed above? (other than programming skill level)

You might also check out the community MQTT-Beta app to see if they pass physical switches.

I would love the Maker API to pass physical switch events and accept color maps.

1 Like

I will definitely check it out as I was already messing with MQTT and NR. This might well be a way around having to build something for my corner case from scratch.

1 Like

If you get it to work, post back!

It is my understanding that Maker API is not sending it.

It is my understanding that Maker API will start sending these events with the next platform update.

I thought I had read previously in the thread that the Maker API didn't send it, but if feels like cheating for it to include it in the log, but not in what is sent.

When you say next platform update are you referring to the digital vs physical distinction or both that and the redundant on command?

Hubitat 2.2.0 will send the event type as part of the event. So if the driver populates the event type field (typically as physical or digital), it will be passed along after Hubitat 2.2.0 comes out.

Of course, support for that field will also have to be added to these Hubitat node-red nodes as well.

Not sure if that will help your specific case, as they doesn't fix/change redundant/repeated event behavior, but thought I would mention it.

1 Like

This.

I look forward to that release and hope that others are interested enough in that data on the NR side for that to get updated thereafter. As always I appreciate the community that makes all of this progress. I am living off the fine work of many others and that is how I find the next barrier that I hope gets addressed.

Given how incredibly responsive @fblackburn has been, I'd say the odds of that happening are really high.

1 Like

For the redundant events, what does the device EVENT log show (not the system log)? Maker API only sends events that are actual events. If it is truly duplicate, or a log message only, Maker API will never send it.

Anything you see as an event in the device event log should be sent though.

If there is a log message that you want/need to be an event, but doesn't show up in the devices event log, then you need to have the driver author make the message a state change event so it won't get de-duped. If it is an in-box driver, good luck - probably won't happen/won't be changed.

The device log is showing the redundant on:

[dev:33](http://192.168.86.110/logs#dev33)2020-04-07 01:05:06.315 pm [info](http://192.168.86.110/device/edit/33)Master Light Overhead was turned off [digital]
[dev:33](http://192.168.86.110/logs#dev33)2020-04-07 01:03:44.217 pm [info](http://192.168.86.110/device/edit/33)Master Light Overhead is on [physical]
[dev:33](http://192.168.86.110/logs#dev33)2020-04-07 01:03:21.870 pm [info](http://192.168.86.110/device/edit/33)Master Light Overhead was turned on [digital]

In this sequence I did on digital, on physical and off digital, but only the first on and the first off showed in Maker API log.

Are you sure that is the device log? Those look like lines from the system log. There are often events listed there that are not entered as actual events into the system. I know in my drivers I put a bunch of messages there that I don't make "events" for...

Go to the device, click EVENTS at the top. If the events are all there, then you should be good. If they are not all there, then the driver would have to be changed to make Maker API send them.

Ah, I see the distinction you are driving at. In the events log for the device it is not showing the duplicate:

Name Value Unit Description Text Source Type Date
switch off Master Light Overhead was turned off [physical] DEVICE physical 2020-04-07 01:48:39.499 PM CDT
switch on Master Light Overhead was turned on [digital] DEVICE digital 2020-04-07 01:48:15.927 PM CDT

So as you said using the built in generic z-wave driver may be a lost cause. This is a slightly different example as my sequence here was on digital, on physical, off physical and the middle (redundant) on physical made the system log but not the device events log.

Depending on the device, there may be a user developed driver that has more flexibility in event creation.

nice catch, it's a similar issue that @JasonJoel already reported for input device node (fixed in 0.0.27). A quick look in the code seems that it can also happen in the device node. I will need to add some tests to confirm and fix it

Do you have screenshot (of node status) or log when it happen?

2 Likes

Hmmm I dont think so at this point (have been doing a lot of different stuff). I will keep an eye out though for new occurrences and send asap.

edit: the node status was "undefined" with red box with an X in it I think (on the flow page).

Yeah sure, I've created an issue to clarify that it will be supported :stuck_out_tongue:

And the previous log you post with events received by NR it's all what Maker API send. So when it will be released, you should see it in the same log

1 Like

fixed
It occurs if you have node that modify the event sent by the device node
I should release a new version soon

5 Likes

I managed find some interesting things today while looking for how to get input from a switch that was already on without turning it off. Here is what I have found:

  • For the GE/Jasco switch that I had been using the generic z-wave driver, it worked with the GE-Jasco Z-Wave Plus Switch that was created by @JasonJoelOld who is probably one and the same with @JasonJoel.

  • This driver reports doubletaps up (button 2) and down (button 1) even thought my switch has no buttons

  • I even saw the doubletapped attribute in the NR hubitat device node created by @fblackburn.

  • Unfortunately, this node only gets a reading from hubitat on deploy and what it gets is whichever "button" was doubletapped last. Edit: Turns out this was fixed somewhere between v.0.27 and 0.29 and so I when I upgraded that fixed this issue. I mention it in a later post

  • However based on the suggestion of @erktrek, I looked into the MQTT client for Hubitat that is currently in beta from @kevin
    When combined with Joel's driver, I would get 2 items through MQTT whenever a doubletap occurred. The homie/main-hub/master-light-overhead/button/button-1 or homie/main-hub/master-light-overhead/button/button-2 topic would get a doubletapped value followed by an idle value about 1 .3 seconds later

Putting all of this together is not to hard since I was already integrating MQTT into my environment, but it is a bit of Frankenstein approach if you don't already have an MQTT broker that Node Red is interacting with. It also isn't quite what I was originally shooting for which was to be able to take action based on an up on the switch that is already on, however the difference between an up and a doubletap up is virtually minimal.

Edit: So net-net I now have 2 different methods of getting events from HE to NR. This feels totally in keeping with my Node Red experience as every time I do something I think of 2 or 3 other ways I could do it.

In closing thanks again to the members of the forum who are full of ideas and @JasonJoelOld, @kevin, @fblackburn and the Hubitat team who actually wrote the code needed to make this work.

2 Likes