App and driver porting to Hubitat

see I knew there was a reason I posted here instead of messing with it all day hahah Ill look into this new one as it sounds way more capable. Thanks for the link

Search is your friend :wink:

1 Like

Yeah I've often said that to other people.. I guess I just got focused on porting over my existing handler instead of looking for a new project. hence how I found this thread haha. This integration works way better than my old one so thanks for the solid recommendation!

Would be nice to see this community post converted over to the new docs.hubitat.com if that is the new home for official documentation.

2 Likes

Is it true that we are replace st with he? I vaguely recall seeing that a few weeks ago, but cant find it now, and st and he are too short on which to search.
such as this:
"st cmd 0x${device.deviceNetworkId} 0x12 0x0006 0x0 {}"

4 posts were split to a new topic: sendHubCommand in Driver

remove ("any text")

Not supported
Change to paragraph "text"

1 Like

findAllChildAppsByName('app name')
fails with
groovy.lang.MissingMethodException: No signature of method: app15434399313021801853038.findAllChildAppsByName() is applicable for argument types: (java.lang.String) values: [SHM Delay Simkypd Child] on line 1062 (keypadModeHandler)

ALso setting label name from an input setting does nothing
input "simkeypad", "device.InternetKeypad", multiple: false, required:true, submitOnChange: true, title: "Simulated Keypad Device"

	if (simkeypad)
		{
		section() 
			{
			label title: "Profile name", defaultValue: "Profile: Ikpd: ${simkeypad}", required: false
			}
		}

Need some help converting the following ST zigbee library code
log.debug "Sending Status ${zigbee.convertToHexString(status)}${zigbee.convertToHexString(seconds)} to device..."

keeps throwing
[error](http://192.168.0.106/device/edit/194)groovy.lang.MissingMethodException: No signature of method: com.hubitat.zigbee.Zigbee.convertToHexString() is applicable for argument types: (java.lang.Integer) values: [2] Possible solutions: convertToHexString(java.lang.Integer, java.lang.Integer) on line 449

I've tried Integer.convertToHexString and integer.convertToHexString, both fail.

I hope someone has an answer.

From ST documentation:

zigbee.convertToHexString()

Convert the given value to a hex string of given width

Signature:

zigbee.convertToHexString(Integer value, Integer width)

COPY

Parameters:

  • value : Integer value to be converted
  • width : the minimum width of the hex string. Default value is 2

Looks like you need a second "width" parameter

Maybe
${zigbee.convertToHexString(status,2)}${zigbee.convertToHexString(seconds,2)}

:man_shrugging:

OR
you may need to convert "status" and "seconds" to integers beforehand

${zigbee.convertToHexString(status.toInteger())}${zigbee.convertToHexString(seconds.toInteger())}

This one is my guess. But I haven't used that function in HE, that I can remember.

I believe there is a second parameter to that function

zigbee.convertToHexString()

Convert the given value to a hex string of given width

Signature:

zigbee.convertToHexString(Integer value, Integer width)

COPY

Parameters:

  • value : Integer value to be converted
  • width : the minimum width of the hex string. Default value is 2

:+1: Thank you, that fixed it! I swear I tried that before asking for help and it failed. However, this time it worked. I guess the default value, 2, did not make it into HE.

@mlciskey @JasonJoelOld Thank you for responding.

2 Likes

driver sendEvent difference
In a driver after issuing a sendEvent for an attribute,

sendEvent(name: "armMode", value: armMode)

then subsequently in the same event issuing a

device.currentState("armMode")

the value of the attribute at the beginning of the event is returned, not the current actual value as done in ST

The solution

2 Likes

Again, I want to caution that using this method can add more load on your hub that is not needed. It does not make sense to set a value and then immediately look up that same value in most cases.

1 Like

I agree with you. If the purpose is to validate that a command took, a runIn() call is the more efficient way to handle it. In my opinion. And that's exactly how I implemented the test procedures in my Z-Wave Repeater driver.

I understand. However, sometimes a low level of overhead is easier when porting a ST DTH to a HE driver

In my situation I have an easy workaround and when I tried the true option it did not work.

Edit: As Chuck mentioned the sendEvent command is queued by the system, so even using the "true" option may not get the value in the sendEvent command because it has not executed. If you bump into this fix the logic or code a workaround.

Couple I've found.

isNumber() and toInteger() are both string functions (for converting numeric strings to integers). Also toDecimal(), etc. According to Groovy spec, that is.

On ST, if you pass these an integer, they fail silently/gracefully. In HE, they error out. I'd argue ST is wrong to have them fail silently, but it's a difference that will have you pulling hair out as you go and change all your variable "checks")

findAllChildAppsByName('app name') fails
groovy.lang.MissingMethodException: No signature of method:

Is findAllChildAppsByName('app name') supported?

If not, does getChildApps() work?