Node-RED nodes for hubitat

[danfox52]

Try turning off logging on the Maker API app in HE.

[aaiyar]

@danfox52

turning off logging

I don't have it turned on. And I still run into the issue occasionally.

[erktrek]

Okay I turned it off will let you guys know if it helped.

[erktrek]

So another weirdness. I disabled logging but then included a generic zigbee motion sensor. I updated the maker api and node-red but the device node was not showing motion. Tried various things, updating, replacing node etc and nothing worked until I re-enabled debug logging. After that it started showing motion events. I then set debug logging off and it was still working...

[tmichael]

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)

[erktrek]

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

[OLD] MQTT app beta1 and pre beta2 - please use beta3 thread

It's been a long wait but I have, at last, released my mqtt app as an open beta 1 this weekend. It's still evolving and although it won't win any coding awards it is pretty feature complete and stable I hope. It's been through 5 major alpha releases and numerous smaller updates with over a hundred alpha testers although feedback has been very limited saddeningly. For those in the smaller alpha testers groups - thank you so much for your feedback, it's been invaluable ..There maybe a few b…

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

[tmichael]

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.

[erktrek]

If you get it to work, post back!

[aaiyar]

@tmichael

the maker API is not sending it to the NR node

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

@tmichael

is there any reason I couldn't build my own special purpose version of the maker API

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

[tmichael]

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?

[JasonJoel]

@tmichael

distinguish between physical and digital switching to on of switch

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.

[aaiyar]

@tmichael

digital vs physical distinction

This.

[tmichael]

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.

[aaiyar]

@tmichael

others are interested enough in that data on the NR side for that to get updated thereafter

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

[JasonJoel]

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.

[tmichael]

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.

[JasonJoel]

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.

[tmichael]

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.

[JasonJoel]

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

[fblackburn]

@erktrek

I'm having a weird issue where periodically some of the HE Device nodes "forget" which attribute they have. Probably after a deploy but not sure. The only reason I picked up on it was it happened twice fairly recently to some virtual switches on HE.

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?