Node-RED nodes for hubitat

⚙️ Custom Apps and Drivers Node-RED
4371

yes, that behavior seems to work fine and that is how I have reconfigured things.

the setColor command node, however, seems to be interpreting hex values strangely.

4372

command node is only a proxy to Maker API. There is no logic or magic before sending the command. You can try directly with Maker API (copy/paste in your browser):

http://<ip>/apps/api/<app_id>/devices/<device_id>/setColor/{"hex":"15fe21"}?access_token=<token>

If you get the same result, then probably that community can help you better than me (I have never used this command)
If you don't get the same result, then it may be related to the command node

4373

yup. same result. I’ll see if I can run it up the chain.

thanks

4374

@fblackburn Can you remind me what the status is of COMMAND NODE logging? I keep seeing 3x events in rapid succession on some end devices that I am trying to troubleshoot. I expect it is a logic or node-red issue, not a command node issue - for the record.

But there is nothing from the command nodes being logged in the node-red log at all - just device nodes.

I have not went back and turned on debug/additional logging on the node-red side yet. Is that what is currently required to get logs of what the command nodes are doing?

4375

Currently, there is no logging in this node. To know if command is sent or not, you need to check the msg.response from the output message.

  • If you have connection issues: then you should have log in NR interface and in the node status with a red dot (and no output message)
  • If you have value/command issue, then the msg.response should have some plaintext/weird error
  • If everything is ok, then msg.response should return the device properties (the same output that if you try the Maker API command endpoint in your browser)
4376

Good idea. In my case it is happening at specific trigger times in Node-RED, so I don't believe it to be a communication issue.

Like any troubleshooting, step 1 is to scope the issue. AKA figure out whether node-red is really SENDING 3 commands to Maker API or if it is the hub side that is doing something unexpected.

If Node-RED is really sending 3 commands, it is likely a logic/concurrency/timing issue.
If it is not, then it is a Maker API, hub, or zwave mesh issue.

I can dump the output of the command node to console so I can look back when the events happen.

Thanks.

4377

Is there any way to get HE hub details in Nodered? It looks like the info is available (I’m primarily interested in the firmware version) but not sure it’s exposed to the Hubitat nodes

image
image626×1202 103 KB

4378

The hub version is included in the systemStart event description text and value. So while you can't get it "on demand" you could probably catch the systemStart event and store the value (which is the hub version) in a node-red variable.

Disclaimer - I didn't actually try this.

I would use the location node instead of the event node, as it is somewhat pre-filtered. So just run locaiton node into a switch node then change node and set a global variable to msg.payload.value if msg.payload.name="systemStart".
image
image

1 Like
4379

I’d have to look it to be sure, but I believe this data is exposed in the HE API for drivers and apps (mainly to verify compatibility with developer’s code). Shouldn’t be too hard to create a device or other object to expose it to the MakerAPI (may actually be there too, haven’t checked).

3 Likes
4380

Could definitely do it that way, too, if you want to do a little coding. It is definitely available in apps - I've done that before. I don't think I've ever tried to get it in a driver before, but I bet you could.

EDIT: I checked the dev docs, it says the hub object is available in both apps and drivers, so you could make a simple virtual driver that grabs version and stored it in an attribute. Then the normal device node could be used to get the value on demand if desired.

3 Likes
4381

Had some code laying around:

 /*
 * Hub Info
 *
 *  Licensed Virtual the Apache License, Version 2.0 (the "License"); you may not use this file except
 *  in compliance with the License. You may obtain a copy of the License at:
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 *  Unless required by applicable law or agreed to in writing, software distributed under the License is distributed
 *  on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License
 *  for the specific language governing permissions and limitations under the License.
 *
 *  Change History:
 *
 *    Date        Who            What
 *    ----        ---            ----
 *    2020-12-07  thebearmay	 Original version 0.1.0
 *    2021-01-30.                       add hub version
 */

static String version()	{  return '0.2.0'  }

metadata {
    definition (
		name: "Hub Information", 
		namespace: "thebearmay", 
		author: "Jean P. May, Jr.",
	        importURL:"https://raw.githubusercontent.com/thebearmay/hubitat/main/hubInfo.groovy"
	) {
        	capability "Actuator"
		
		attribute "latitude", "string"
		attribute "longitude", "string"
        attribute "hubVersion", "string"
		command "configure", []
            
    }   
}

preferences {
	input("debugEnable", "bool", title: "Enable debug logging?")
}



def installed() {
	log.trace "installed()"
}

def configure() {
    if(debugEnable) log.debug "configure()"
    sendEvent(name:"latitude", value:location.getLatitude())
	sendEvent(name:"longitude", value:location.getLongitude())
    sendEvent(name:"hubVersion", value:location.hub.firmwareVersionString)
}

def updated(){
	log.trace "updated()"
	if(debugEnable) runIn(1800,logsOff)
}

void logsOff(){
     device.updateSetting("debugEnable",[value:"false",type:"bool"])
}
6 Likes
4382

Yep - I saw that in the Location node. I was going down the path of storing the value but that would require me to change NR to context storage (to persist NR restarts) and muck with the settings file. Was hoping that I could avoid that but may have to go with that.

4383

Or you can use @thebearmay's driver for a virtual device (the post just above yours).

2 Likes
4384

Going to try this but have no idea what type of a virtual device :thinking:

4385

I don't know how people can live without persistent context variables. :wink:

I use them extensively.

2 Likes
4386

It will be obvious when you do it...

  • save the new driver as a user driver
  • Make a virtual device, specify that driver as the type/driver to use.
  • voila
3 Likes
4387

My NR setup was relatively simple so never set it up that way :pensive:. Time to grow up I guess..

1 Like
4388

I just set this up. It's a simple edit to the settings.js file I recall. Actually the option is already in the file and just needs the commenting to be removed, and presto! Persistent Context Variables!

3 Likes
4389

If I get some time today I’ll flesh that code out some more and see if I can subscribe to the system start event to force it to update automatically.

4 Likes
4390

Or just add initialize capability and do it in initialize().

2 Likes