I keep fighting with the thermostat

@thebearmay is on the right track, the reference in the log indicates the app is logging the error and the line reference is most like for the app code, not the driver, so I think the sendEvent call is not related The driver will need a capability reference towards the top for refresh, as well as the refresh command defined and implemented.

I found this in the scheduler were the thermostat is connected

I can only assume that is a scheduled job designed to, amongst other things refresh the status info for the thermostat, which, if I am right would want to call a method / command called refresh.

Let me find you an example from my own driver.

1 Like

Look at lines 25 and 43 in the code below, 25 calls out that the driver implement's the refresh capability and 43 is the start of the refresh method that defines it.

I am expecting this method should call / run the code to updates the thermostat device in HE with the current state for the actual thermostat. Putting this code in there should also result in a refresh button appearing on the device setup page you showed earlier.

1 Like

OK but what i can do ?

If you want to take small steps to test the theory, add the capability reference to your code (line 25 from mine), and add an empty refresh method or simply one that records a message in the logs.

Actually, one thing I forget to ask, did you develop the driver or someone else?

1 Like

No i downloaded this

Ok, then I would say if you are willing and able then you could tinker with the code like I was suggesting, or simply send a message to the developer. You should send him a message even if you do update the code, letting him know about the issue and the results of your testing.

1 Like

I think is better ask

1 Like

No worries, I'm happy to help out if he needs a hand.

1 Like

Thanks
Maybe you can send me the line to copypaste :slight_smile:
i'm a sw developer but not in this
So i don't want to make mistakes

1 Like

I would add to the device driver code the refresh capability inside the "definition" section (see line 25 from my code linked above):

capability "Refresh"

And then the refresh method anywhere after the end of the "metadata" section:

def refresh() {
  log.debug("refresh: Refresh process called")
}

Once you are happy this stops the error from appearing in the logs and the debug message appears in its place with a link to the device rather than the app in the log entry, then you know this capability and method are what need to be added to the driver. The code above will not be enough on its own, however, eventually the code inside the refresh method should be added to, updating any state variables and attributes of the device appropriately, but first we want to confirm this is the right approach.

Simon

2 Likes

I Try :slight_smile:

1 Like

image

WOW My first experience! ahahaha i'm not virgin anymore now :slight_smile:

2 Likes

Sorry bad umor :slight_smile:

All good, no problem from my end :slight_smile: Welcome to the club.

In terms of the next steps, you could either look through the code in the driver to find what may be the right calls to add into the refresh method to actually refresh the status of the device, or you could pass this over to the developer with this as a starting point for what he needs to change in the code.

1 Like

I think the right thing is to let the developer do it. @nclark
I have wrote him a message too :slight_smile:
Thanks for the help again
I have to study a bit this language too :slight_smile:

1 Like

I'll take a look at exactly what I need to get refreshed if at all needed, but I'm guessing that I'll just need to be trying to refresh the temp sensor(s) that are associated with the virtual device?

In my case, i.e. the driver I have been developing, it is things like the room temperature, set point, operating mode / state, etc. But yes, I think you are right in your case.

1 Like

Don't know if it helps
In my case I will also change the setpoints using rules.