Pass value to rule machine custom command bug

[kahn-hubitat]

is this not possible it seems to get the value but not pass along as a parameter..

[ogiewon]

Please show the custom action where you configure the data type you’re passing to the command. You may need to change the type from string to number/decimal.

[kahn-hubitat]

i've tried both decimal and number and neither work.. here is the code.

def setThermostatSetpoint(setpoint) {
log.debug "Executing 'setThermostatSetpoint'"
def result = parent.setThermostatSetpoint(this, setpoint)
if (result) { refresh() }
}

def setThermostatSetpoint(child, setpoint) {
def setpointCelcius = farenhietToCelcius(setpoint)
wake(child)
pause(2000)
return executeApiCommand(child, "set_temps", body: [driver_temp: setpointCelcius, passenger_temp: setpointCelcius])
}

i will try string now.

[kahn-hubitat]

string doesnt work either

it works fine direct from the device handler page.

[ogiewon]

It appears the error is being thrown from your custom app, correct? Perhaps if you declare the data type in the custom command’s list of arguments? I am just guessing...

Like

def setThermostatSetpoint(float setpoint) {
log.debug "Executing 'setThermostatSetpoint'"
def result = parent.setThermostatSetpoint(this, setpoint)
if (result) { refresh() }
}

Also, what does your custom command declaration look like at the top of your driver? You probably need to be explicit there as well.

@bravenel would probably know for sure.

[kahn-hubitat]

just tried that declared it as number in both pieces of code.. and it still works from device handler panel but now i get this error..
i also deleted and redeclared the variable as number as well,

[kahn-hubitat]

it is declared as number at header so this should work? It always has been that way, so i think adding the implicit parameter type did nothing that is why the error message is the same.. thanks for looking.

	attribute "state", "string"
    attribute "vin", "string"
    attribute "odometer", "number"
    attribute "batteryRange", "number"
    attribute "chargingState", "string"
    attribute "refreshTime", "string"
    attribute "lastUpdate", "string"

	command "wake"
    command "setThermostatSetpoint", ["number"]
    command "startCharge"
    command "stopCharge"
    command "openFrontTrunk"
    command "openRearTrunk"
    command "unlockandOpenChargePort"
}

Also just tried number with capital N .. same issue. dont think case matters here.

[bravenel]

%value% is a string. Where are you converting that to a number? From the logs, you're passing a string "set to 69 by Rule Machine" to a number parameter. How is that supposed to work?

Please show the Custom Action setup page. That's where the issue lies, evidently.

[kahn-hubitat]

thanks it cannot be a string as the fx requires a number so i will have to create a new fx that is a string and then convert to a number and call the other fx.. thanks for your help.. good to know that value is always a string.. That helps quite a bit.

your right it is set to "set to 69" but how did it ge tthat way.. i did not set it that way.. i just have a dashboard that has a variable.. see attachment.. something is screwy here..

so how is the variable getting set to that weird value????
ya there is something wrong with the variable passing from the dashboard or the rule binding, it should not be that string just the numeric value

[bravenel]

Why don't you just use the variable that triggers the rule instead of %value%?

I can see in the code where %value% is being set to that string. Should it be set to the variable's value? Probably; but this is what happens with a variable trigger (always has). You do have direct access to the value in %Tesla Temp%.

I will look into changing how %value% is set for a variable trigger. This would be needed if there were multiple triggers possibly with multiple variables, so using %variable-name% would not be so easy.

This change has been made, and will be in the next release.

[kahn-hubitat]

Thank you. I didn't know I could use the variable directly. I will.go ahead and use it. Thanks for looking at it. If that is the way it has been I wi
Wouldnt worry about it. Except that it is slightly confusing. Probably good to change though as you say for multiple variables.