New version 0.0.30
Changes
4 Likes
No idea what that means. If it makes an event, Maker API sends it Node-RED. All of them.
Edit: I apologize if that sounded snippy. It wasn't meant that way.
Edit: Now it is my turn to apologize. I saw the announcement of version 0.30 and thought, why don't I see if that has any effect. I went to upgrade and found that I could only get to 0.29, but the version I had been experiencing this problem with was 0.27. I upgraded and low and behold I started seeing doubletap events via the device node. I guess it hard to keep up with all the great work going on. Please ignore everything below this in this post.
Misguided Earlier version of post
I agree that this has been my experience using these nodes in NR with the Maker API. What I am experiencing is when I use the driver, and I connect to the Maker API and select that device, I get 5 options in the Attribute dropdown. They are Undefined, doubletapped, numberOfButtons, pushed and switch.
When I created 5 device nodes and wired them to a debug node, I got different results than I had hoped for. The Undefined node seems to receive nothing (not that I really expected anything). The switch node did exactly what I am familiar with. It pulls the current state on deploy and then changes that state (and sends event to the debug node) every time I turn the switch on (physical or digital). The pushed node initially populates the readout below the node with pushed: null and doesn't change when I manipulate the switch. The numberOfButtons node is like the pushed node in not changing, but it show the readout below the node of numberOfButtons: 2. The doubletapped node is the oddity that I was referring to. When I first deploy the node, it either show doubleTapped: 1 or doubleTapped: 2 . Which it shows is dependent on which ever way I had last physically doubletapped (really more of a double click) the switch.
If I leave that flow and turn the light on or off, the readout below the switch changes to the selected setting and it sends an output to the debug node, but doubletapping does not pass through the API to the doubletap node, regardless of if the doubletap matches the original readout or is opposite of the original readout. But if I start it with doubleTapped: 1 and then do a doubleTapped of 2 and then redeploy the flow the readout below then node changes from doubleTapped: 1 to doubleTapped: 2.
Obviously the driver has some idea it is happening as it shows in the device events and 2 events are passed to the MQTT app, but for whatever reason some combination of the driver, the maker API and the device node don't register it as an event. (I did even double check that the device node had send events checked)
In the end it is only a minor concern since I can use MQTT for what I need. If anyone wants to try to troubleshoot, I would be willing to share logs etc, but only to help others, not because I need it fixed for me.
That makes me feel a lot better!!! LOL. That is what I would expect to happen, so I was really wracking my brain trying to reproduce that on my end.
No worries, and glad it is working.
How to refresh the palette so it updates. (I know how to update, just NodeRed not showing an update for Hubitat, it's still at 0.0.29)
This has likely been asked before - if so apologies... Is there a way to see all property values of a device node at once? I'm trying to sync color lights to virtual lights in HE and I'm having to dance around up to six or so separate device nodes with different properties and hoping they all come through at the proper time. Would be nice if I had one node that sent an array of properties in the payload so I could parse them all directly with one msg. Maybe an option to send all?
Thanks again for all your hard work and opening my eyes to the incredible potential of NR.. it really is mind blowing.. 
edit: @JasonJoel also gets huge thanks as well for all his discussions on NR over the past year or so (maybe more!) - very interesting and informative. Totally inspired me to try it out.
2 Likes
Unless you want to manually pull it from his git, you just have to wait until the servers all get updated. Refreshing your browser and going back into palette management refreshes the list, too.
2 Likes
It should be up - just updated mine.
check it with
npm outdated
Also in your package.json file make sure the hubitat entry if there is one is prefaced with a "=>"
3 Likes
It showed up for me, too. Sometimes it takes an hour or so for the servers to all replicate/sync. I don't think it has ever taken more than a couple hours to show up for me after he pushed a new version.
3 Likes
Just curious... When we update, we have to restart Node Red afterwards but I rarely have to do that with other palettes. What does the restart do? What's different?
The way I understood it, you should always have to restart when updating nodes that are in use. It can't swap in-use nodes out on the fly.
If you update nodes that aren't being used in a flow, then you don't have to reboot (I think).
But I could be wrong? I can't remember the last time I updated a node type and wasn't asked to reboot, though.
2 Likes
I honestly don't remember doing it on other palettes but that's probably because most of the others are not updating with the frequency that the Hubitat Nodes have been. That's good to know. Thank you.
Ah, found it. Good ole Node-RED documentation:
https://nodered.org/docs/user-guide/runtime/adding-nodes
"Whichever approach you take, you will need to restart Node-RED to load the updates."
You already knew this but YOU ARE RIGHT! I went thru my Palette Mgr and Bigtimer needed to be updated and it told be to restart after. I have also realized that I have downloaded a lot of palettes that I thought would be helpful but are unused and now being deleted.
I did the same .....
I tend to collect a bunch, then every once in a while clean them back out. It is pretty tidy right now, though.
Wanted to clarify my feature request for a Device node.. and add one new thing maybe..
Would like an "** ALL **" (or something similar) option added to the "attribute" dropdown. Once selected you would then have the option of either choosing "send selected event" or "send all events".
Another way adding yet another feature would be to instead add "** current attribute **" to the attribute list and then separately at the bottom give the option to "send events for all attributes" checkbox near "send events" or something like that. The "current attribute" would just send whatever fired.
edit: I like my 2nd idea better... 
@stephen_nutt : thanks for posting the Alexa CSRF fix over on that NR forum. Deleting the authFile, restarting NR and re-authenticating got me back up and running
It was for when the authentication for node-red-contrib-alexa-remote2 goes haywire
This is the post
1 Like
