I am using a Hubitat C7 hub and Inovelli Red Dimmers. This one switch is using firmware 0 of 1.161 and firmware 1 of 1.45. I set params 18, 19, and 20 to 0. However, every 10 minutes I am still getting reporting. How do I stop these reports?
Do you know what is calling the “refresh()” method. That is what is causing the switch to send the reports. The hub is requesting them.
No. Lol. I was hoping you could tell me. But from the below, it looks to me like the refresh() command is in the driver. I thought it was coming from having log debugging on as when I turned that off I didn’t see them any more in the logs. @BertABCD1234 responded that he wasn’t sure and thought it might still be generating traffic, but it just wasn’t being reported in the logs. He suggested tweaking the driver code:
If you just want to turn off the messages, than you can just disable the logging.
There might be an app that is calling for a “refresh()” every 10 minutes so check to see which apps are using the device. I do not believe the refresh method gets called on its own.
Some people have used a “Z-Wave Polling” app or have put “refresh” into other apps / rules they are using.
1 Like
This is my assumption, too. I don’t use Inovelli’s drivers for these (I wrote my own), but I don’t see any calls in the code that would schedule a periodic refresh(), nor did the poster see any “Scheduled Jobs” in the driver that would suggest it’s coming from the driver code. And I’m guessing you wrote it, so I suppose you’d remember, too. 
(But with this regularity, it’s almost certainly something periodic/scheduled.)
My assumption was also an app, though aside from the Alexa and Google Home integrations, I didn’t see anything obvious in the cross-posted-and-double-posted-here Hubitat Community post. (I don’t think Alexa or GH alone would do this, either, but how they work isn’t as apparent as simple apps or rules you set up yourself…)
In any case, if the goal is to determine whether the reports actually stopped and not just get rid of the log, I think the tiny code modification I suggested in the other post would work. I don’t see a reason that simply having debug logging enabled should affect reporting, so that’s why I’m suspicious…
Zwave polling might be setup to accommodate some other zwave device that doesn’t report changes by itself. Some GE/Jasco dimmers don’t report their final dim level correctly unless you poll or employ other means to capture it as an example.
I realize a lot of Inovelli users are also Hubitat users, but, of course, it is not a one-to-one relationship. I also do try looking for other posts in both places before posting, and if I do find posts in both places if they are by the same people.
As to posting in more than one thread in the same forum, I may see something that is, if not right on point, is somewhat close, but is old. By posting in multiple places that will send an email to those other posters who may not be looking in unless they have an issue. In this instance I first thought it was power reporting and it then turned to to having debug logging turned on, along with a quest to figure out what is sending the refresh call. So that could, and did, lead me to other threads.
I don’t know anything about Java, Python or any of the C family or whatever code the drivers are written in. In fact, I don’t even know what language they use. So, while modifying the code as suggested may be at the coding 101 level, when it comes to this language I’m at level zero.
I appreciate all the time Bert and others have put in trying to help me, and I don’t expect them to change any of their driver’s code, but I’m just not comfortable experimenting with driver’s code. Even if I figured out how to look at the code, and found a refresh() call, I’m not sure if I could tell if it was being called periodically or what was calling it, let alone if there was any safe way to limit that.
So I realize their is frustration in my posts, but since there isn’t any official tech. support I can call I need to reach out to as many volunteers as I can, as quickly as I can. BTW, I also realize that because Inovelli and Hubitat as so small they may not be able to have call-in support, so I know these forums are they only real way to get support.
Ultimately, are you still placing blame on Inovelli here? I think we have clearly established that the hub itself and NOT the switch or driver are to blame for the refresh() commands, so this is more of a Hubitat thing than an Inovelli thing.
Totally understand the frustration if these are crippling your hub (says more about the hub than the switch IMO).
I’m not on Hubitat, for reference.
You’re using Inovelli’s driver, right? So you had to install the code at some point. (Whether you did it yourself or via HPM, but even if you used HPM, that is custom code, too.) If you’re dealing with the LZW31-SN driver, all you’d need to do is go into Drivers Code, find the Inovelli LZW31-SN driver you’re using, open it, and replace line 1385, which should read:
if (debugEnable) log.debug "refresh()"
with:
log.debug "refresh()"
i.e., just remove the if (debugEnable) part. Spaces and tabs don’t matter, so there is truly nothing you can mess up here if you just change that part of the line, no matter how you do it, and if you still mess up, all you have to do is paste Inovelli’s current driver code over your modifications like you did to install it the first time (or run a repair if you used HPM).
I know it seems daunting if you aren’t into code, but I promise you, nothing will be messed up if you do that — and it’s that easy to go back even if you do.
This is what I mentioned in the other thread (another reason, IMHO, that it’s confusing to spread these requests across multiple threads and forums, but I digress).
In any case, I still suspect the problem originates outside the driver, with some app/automation on your hub calling this command periodically. This is just a way to verify that disabling debug logging isn’t simply hiding the problem (because I don’t see any reason that its state should affect whether refresh() gets called).
I think this would be fairly simple for somebody using Hubitat to verify to help this guy out.
The refresh() command is being called exactly at 10 minutes. If it were the driver, anybody using that same driver should see the same in their logs. If it’s not there, then there is something else calling the refresh() command.
I also think it should be fairly simple for @skarden to troubleshoot on their own. All that they should need to do is temporarily switch the device type to a generic light switch driver, wait 10 minutes and check the log. If refresh() is still being called then they can easily rule out the driver as the culprit.
I’m of the same mindset as bert here. I suspect it’s an app or automation calling the refresh() command on the device.
The symptoms definately point to something like that going on. I highly suspect the Z-Wave Poller App is polling this device
1 Like
So I went into my Red Dimmer code and found Refresh() is being called in 2 places and is defined just below that (lines 1374-1391)
def ping() {
if (debugEnable) log.debug “ping()”
refresh()
}
def poll() {
if (debugEnable) log.debug “poll()”
refresh()
}
def refresh() {
if (debugEnable) log.debug “refresh()”
def cmds = []
cmds << zwave.switchMultilevelV1.switchMultilevelGet()
cmds << zwave.meterV3.meterGet(scale: 0)
cmds << zwave.meterV3.meterGet(scale: 2)
return commands(cmds)
}
Do I need to change the Ping, Poll and Refresh functions?
What should I be looking for in a before and after test?
Also, I do have the Z-Wave Poller app installed, but it isn’t polling anything:
I wouldn’t, all those methods do the same thing, but they are there for compatibility with other apps.
Based on the debug log you posted previously it doesn’t look like Ping or Poll are being called first. Some app you Refresh on this device. It may not be z-wave poller. If you can show a list of all you apps we might be able to make an educated guess are which other app might be doing it
I don’t see anything in that code that would set up a refresh on a 10 minute interval. That would need to be coded.
But why do you have the z-wave poller app installed if it’s not polling anything? Had you previously set it up to poll something? Do you have an automation setup in RM to poll or refresh the device?
I’d start by removing the poller app (and any other unused apps) and see what happens then.
1 Like
I installed some apps when I first got Hubitat not knowing if I would need them or not. I uninstalled the Z-Wave poller after I took the screen shots below.
I’ve expanded the various apps in the screen shots below:
Basic Skills:
Button Controllers:
Groups and Scenes:
Hubitat Dashboard:
Rule Machine:
Rule Machine Legacy:
Switch Bindings:
Tile Master 2:
Z-Wave Association Tool:
@skarden try this: Go to the bottom of your Bar Lights device page and look for the “In Use By” section. What does that show?
Here is an example from one of my devices
So I’m wondering if its one of your Dashboards. They refresh periodically.
In any case, I would check all those apps that use this device
I was 1/2 wondering that myself. I don’t use them very much, as I usually either physically press the buttons or use Alexa, but they are handy from time-to-time. I don’t know of any way to control them without a dashboard. I saw there was something I hadn’t heard about before called ActionTiles, but I assume they would probably act the same way.
The Dashboard should refresh its contents, but it shouldn’t send a refresh() command to devices themselves. But I’m still not sure what to make from that list of what apps could be doing this, as none seem like likely candidates (except a Rule or Button Rule, which can really do anything you configure, so maybe check you aren’t doing a refresh() in one of those somehow?).
Otherwise, another troubleshooting tip may be helpful: you can disable apps, perhaps one at a time, and see if you can pinpoint it that way when the behavior stops: Apps - Hubitat Documentation. If you aren’t using Z-Wave Poller, I’d also suggest just removing the app, even though you said it wasn’t configured (can’t hurt if it isn’t!). System apps can address devices in ways that don’t necessarily show up under “In use by” on the device page, but most don’t, so it’s not likely, but…again, can’t hurt. 
1 Like