Device Command buttons require a number

[user819]

Hi all,
I'm new to Hubitat. Casualty of Insteon.
I'm trying to add a 4 button Moes Scene Switch. I am assuming it can be used as a button controller.
Moes is not listed as a mfgr so I picked the type as a 'Generic Component Button Controller".
In device setup the command buttons all have a require field I need to populate but I don't know what with.
What am I missing?

Thanks, Steve

[bertabcd1234]

Do you know anything about this device? For example, is it Zigbee? Asking because I don't. But that is what a casual search suggests these devices might be.

Some Hubitat drivers are special. For example, drivers labeled "Virtual" are generally intended only for simulated devices (e.g., for testing) or for devices that do not truly exist (i.e., are virtual and not physical) for whatever reason. The "Component" drivers you're using are also special--they are intended to be used by "parent" drivers that create "child" devices, say, a combination fan/light switch where the fan and light components may be presented as two separate child "component" devices. Some button devices might do this with each device button, too, though with most there's no reason this can't all be done as a single device in the parent driver. But you'd still need a driver that can talk to the device in its particular protocol, which none of these drivers will without a "real" Zigbee (or whatever) driver.

Hubitat has a few Generic Zigbee drivers that might work for some devices like this, but I'm not sure about that specific one. Here is a thread about a device that sounds similar--maybe some of this will apply to you, too?

MOES Zigbee Dimmer Switch

Hi, I recently purchased the MOES Zigbee Dimmer Switch MOES Zigbee Dimmer Switch but I could not find any driver that works with it (not even the basic ON/OFF switching). Did anyone work with this device already? Is there any custom driver that I can use to make it work? Even though I am totally new to HE and Zigbee, I tried to see the event that is sent by the device to HE when I press the button to switch it ON or OFF. What I received was the following: SWITCH ON: catchall: 0104 EF00 01 0…

If so, it doesn't look great since that device is non-standard. These may still be usable with custom drivers, even if there isn't a built-in driver. But if you want to keep things simple, and perhaps you do when you start, then sticking with devices on the known compatible device list will be easier--they have drivers built-in for sure.

Hope this helps!

[user819]

Thank you bertabcd1234.
It is a Zigbee device. But interestingly enough when I read the box again it says it's a Tuya device too. So I did find a type called Tuya Zigbee Scene Switch.
I tried that and saved the device but it still requires to populate the Configure, Double Tap, Push and Release buttons in the device setup.

Looks like I'll end up sending it back to Amazon.

Stevenr.

[bertabcd1234]

@user819

still requires to populate the Configure, Double Tap, Push and Release buttons in the device setup.

Those buttons are just ways to run commands from the driver manually. It can be useful for testing--say, to see if the driver works with the device. Commands like Push require a parameter, the button number. It is normal,for that to be blank when the page loads. You just need to put in any required values before trying to run the command yourself. But that's a bad command to test with for most button devices since that just simulates a "virtual" push and won't tell you if the device is working. A command like on or off would be a better test.

If you manually switched drivers, it's a good idea to run Configure (just press it and wait a couple seconds; you won't see anything happen in the UI). The standard Configure command doesn't take any parameters, so you should just be able to run it, but it's possible a custom driver might do something weird here...

Still no guarantee that it will work, just an idea.

[user819]

Thanks.
I really don't know enough about the drivers to play with that.
It's just that I've added about 8 other devices and none of them have the requirement to populate those fields, until this device.
I'll play a bit more with this and then will see if the device company can help.

[kkossev]

Hi Steve, and welcome to Hubitat!

Some Tuya devices use non-standard Zigbee commands, so these require a dedicated custom driver.
Your device is most probably model TS004F.

The best way to add custom drivers is to install and use the community app 'Hubitat Package Manager'. Then search for and install "Tuya Scene Switch TS004F".

You can also install the driver manually from this link : https://raw.githubusercontent.com/kkossev/Hubitat/main/Drivers/Tuya%20TS004F/TS004F.groovy

[bertabcd1234]

@user819

none of them have the requirement to populate those fields

You don't have to "populate those fields" to use the device. The buttons at the top of the page just represent commands that the driver offers (generally based on what the real-world device does). Commands like "On" or "Off" do not require parameters--they just turn the device on or off. Commands like "Set Level" require at least one parameter, the level (and you can optionally specify a second parameter, the transition time). This is because it won't know what level to set the device to when you run the command if you don't tell it. The button commands like "Push" are a little weird in that these are normally things that come in from the device, not commands you send to the device; for most drivers, these just generate a simulated/virtual button event on the hub, similar to what would happen if you pressed the actual button on the device, but they don't really do anything on the device itself. Either way, you need a button number to go along with the "pushed" event--that's all.

Again, the device page is mostly useful just for testing things like this (e.g., does the driver work?). There is nothing here that you need to do to use the device, unless you want to test how a specific command works. These are not settings or preferences (if the driver has any, those are below this section), and anything you typed in previously will be blank when the page re-loads. That is normal.

Normally you'd set up something in "Apps" to automate the device or use a Dashboard or other solution for day-to-day manual control. For a switch/dimmer, something like Motion Lighting or Basic Rule might be a good place to start; to respond to button events (which, with the right driver, this device will probably send in response to single and multi taps), I might suggest an app like Button Controller. But it all depends on what you want to do.

[user819]

Thanks KKossev,
With the link to the TS004F driver I was able to copy the code and paste it into a user driver and I was able to pick it from the Type list.
However, the buttons still don't work.
I even deleted the Button Controller app I created for it and recreated it with the TS004F but no joy.

[user819]

FYI, I did go to the Hubitat Package Manager link you provided but it was confusing and I didn't see how to accomplish what I was looking for.

I really appreciate your help.

[user819]

Another question for you?
The button controller we are discussing here,

( Amazon.com)

says it requires a Moes Hub.
I could use this Moes hub separate from the Hubitat just to run the controller, but my question is could this 2nd hub connect and control zigbee devices that are already paired to the Hubitat hub?
I'm assuming no but need to ask.

Thank you.

[kkossev]

@user819

The button controller we are discussing here,

( Amazon.com )

says it requires a Moes Hub.

You don't need Moes (Tuya) hub, this is a totally different home automation system (SmartLife) that is entirely cloud-based. Almost all of Tuya branded Zigbee devices can be used locally with the Hubitat Elevation hub.

@user819

With the link to the TS004F driver I was able to copy the code and paste it into a user driver and I was able to pick it from the Type list.
However, the buttons still don't work.

Sorry, I forgot to mention an important detail - you need to pair again the TS004F scene switch to HE hub. Most of the battery-powered Zigbee devices are 'sleepy devices', which means that for power saving their radios are switched off most of the time and they wake up only when a button is pressed, or temperature is changed, etc... So simply changing the driver does not work sometimes. This TS004F scene controller is one of the most difficult devices to pair, as it accepths the proper configuration parameters only at the time when it is paired to a Zigbee hub.

So please do the following:

1. REMOVE the device from the bottom right button on the device web UI page
2. Pair it again to HE hub ( Device->Add Device ->Zigbee -.Start Zigbee pairing). You need to press and hold the bottom left button for 6-7 seconds until the LED starts flashing. Do this procedure close to the HE hub.
3. Once the LED stop flashing, the Scene Switch should be found and after assigning a device name you can now use it. Press all the buttons, try double-click, etc,,. - you should see the actions logged on HE Logs page (open it in another browser tab).

If all is OK, you should see something similar on the device page:

[user819]

Hi kkossev,
Repairing the button controller seems to have worked.
I can see where a button push is showing in the device edit screen.
I am configuring button 1 to toggle 3 lamps. The other 3 buttons to toggle each of the 3 lamps separately.
Problem is many times I push a button and the lamp will turn on and then off with just one push of the button. Sometimes is will toggle properly (push on/ push again for off).
I suspect it's has to do with button bounce as I see log entries for that.

[kkossev]

Can you please post your Model and Manufacturer values? Similar to my post above?

I think I see where the problem may be (your device model is not TS004F, but newly produced TS0044). If this is the case, will send you a fix tomorrow.

[user819]

kkossev,
Thank you.
I see there is some discussion about this very device on other sites like the Home Assistant community, etc.

Here is the back of the device:

[kkossev]

Yep, this device was later made working also in SmartThings, Home Assistant and other home automation platforms...

Your device fingerprint (model and manufacturer and application version) is exactly the model as mine, although my device is missing the MOES logo engraved on the back.

Just recalled that there was a similar problem with another type of controller, that was resolved here:

Device driver function executes twice when called from RM or ABC button press

Hi @garyjmilne , The best approach in my opinion is that if Mike agrees and you send him this remote for checking and solving the core reason of the problem. My driver was written for Tuya devices that are identified as TS004F model and it was not intended to handle TS0044 scene switches, that are supported from the inbuilt 'Tuya Zigbee Scene Switch', which works perfectly with TS0044 devices that were on the market....until this MOES remote. TS004F driver 'debouncing' code is more of a worka…

Unfortunately, I have forgotten to merge the changes into the driver main branch.
Please use the test driver version that can be found in the post linked above (should be 2.4.0 dated 2022-03-31). If these tweaks work for your device too, I will marge it into the main version.

[user819]

Hi kkossev,
I copied the new code into the Tuya driver and saved.
I deleted the device and related apps.
I re-added the device/controller.
I configured the buttons again.
It is still behaving erratically. (toggle on/off with one push of the button or off/on).

I removed the device and button configuration a 2nd time and added the device again. Still the same.
Screen shot is from the driver code.

[kkossev]

On line #73 there is a constant that defines the debouncing time :

@Field static final Integer DEBOUNCE_TIME = 900

Can you try to change the constant from 900 to 1500 or even 2000 for example?
Once you modify it in the Drivers Code editor, press Save and after a second the change will be in effect.

And please post again the device logs (you can try copy and paste as text from the screen).

You do not need to delete and pair the device anymore, once it have been successfully initialized in Scene control mode during the first pairing with this driver, the device will retain the settings.

[kkossev]

These are my device timings:

[kkossev]

I have updated the code from the same link to a new version 2.4.1. Please use this version.

The main change is that the debouncing timer is now started with an explicitly set 'overwrite' (restart) option, although the docs say that this option is set by default, I witnessed the same erratic behavior with the scheduler timer actually not restarted ... At the moment I don't have an explanation for why this happens and why it was not noticed until now, this driver has been in use for quite a long time.

[user819]

kkossev,
I copied in the 2.4.1 driver code and set the debounce time to 1500 and then saved it.
It made a big difference. I haven't seen any 'multiple' toggles when pushing any buttons once. It seemed a bit slower to respond at times so I may reduce the debounce time later.
I've pasted some of the most recent logs below.

Thank you so much for your help. Steve

dev:892022-04-23 04:09:39.057 pm debugdebouncing timer for button 2 expired.

dev:892022-04-23 04:09:37.561 pm debugrestarted debouncing timer 1500ms for button 2 (lastButtonNumber=2)

dev:892022-04-23 04:09:37.540 pm warnignored event for button 2 - still in the debouncing time period!

dev:892022-04-23 04:09:37.538 pm debugcatchall descMap: [raw:catchall: 0104 0006 02 01 0040 00 71A6 01 00 0000 FD 00 00, profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:02, destinationEndpoint:01, options:0040, messageType:00, dni:71A6, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:FD, direction:00, data:[00]]

dev:892022-04-23 04:09:36.772 pm debugrestarted debouncing timer 1500ms for button 2 (lastButtonNumber=2)

dev:892022-04-23 04:09:36.751 pm warnignored event for button 2 - still in the debouncing time period!

dev:892022-04-23 04:09:36.749 pm debugcatchall descMap: [raw:catchall: 0104 0006 02 01 0040 00 71A6 01 00 0000 FD 00 00, profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:02, destinationEndpoint:01, options:0040, messageType:00, dni:71A6, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:FD, direction:00, data:[00]]

dev:892022-04-23 04:09:35.917 pm infobutton 2 was pushed

dev:892022-04-23 04:09:35.915 pm debugcatchall descMap: [raw:catchall: 0104 0006 02 01 0040 00 71A6 01 00 0000 FD 00 00, profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:02, destinationEndpoint:01, options:0040, messageType:00, dni:71A6, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:FD, direction:00, data:[00]]

dev:892022-04-23 04:09:35.885 pm debugdebouncing timer for button 2 expired.

dev:892022-04-23 04:09:35.637 pm debugsendEvent [name:battery, value:100.0]

dev:892022-04-23 04:09:34.355 pm debugrestarted debouncing timer 1500ms for button 2 (lastButtonNumber=2)

dev:892022-04-23 04:09:34.333 pm warnignored event for button 2 - still in the debouncing time period!

dev:892022-04-23 04:09:34.331 pm debugcatchall descMap: [raw:catchall: 0104 0006 02 01 0040 00 71A6 01 00 0000 FD 00 00, profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:02, destinationEndpoint:01, options:0040, messageType:00, dni:71A6, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:FD, direction:00, data:[00]]

dev:892022-04-23 04:09:33.542 pm debugrestarted debouncing timer 1500ms for button 2 (lastButtonNumber=2)

dev:892022-04-23 04:09:33.521 pm warnignored event for button 2 - still in the debouncing time period!

dev:892022-04-23 04:09:33.518 pm debugcatchall descMap: [raw:catchall: 0104 0006 02 01 0040 00 71A6 01 00 0000 FD 00 00, profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:02, destinationEndpoint:01, options:0040, messageType:00, dni:71A6, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:FD, direction:00, data:[00]]

dev:892022-04-23 04:09:32.601 pm infobutton 2 was pushed

dev:892022-04-23 04:09:32.597 pm debugcatchall descMap: [raw:catchall: 0104 0006 02 01 0040 00 71A6 01 00 0000 FD 00 00, profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:02, destinationEndpoint:01, options:0040, messageType:00, dni:71A6, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:FD, direction:00, data:[00]]

dev:892022-04-23 04:09:32.413 pm debugsendEvent [name:battery, value:100.0]

dev:892022-04-23 03:54:50.606 pm debugdebouncing timer for button 1 expired.

dev:892022-04-23 03:54:49.090 pm infobutton 1 was pushed

dev:892022-04-23 03:54:49.088 pm debugcatchall descMap: [raw:catchall: 0104 0006 01 01 0040 00 71A6 01 00 0000 FD 00 00, profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:71A6, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:FD, direction:00, data:[00]]

dev:892022-04-23 03:54:27.624 pm debugdebouncing timer for button 2 expired.

dev:892022-04-23 03:54:26.127 pm debugrestarted debouncing timer 1500ms for button 2 (lastButtonNumber=2)

dev:892022-04-23 03:54:26.107 pm warnignored event for button 2 - still in the debouncing time period!

dev:892022-04-23 03:54:26.105 pm debugcatchall descMap: [raw:catchall: 0104 0006 02 01 0040 00 71A6 01 00 0000 FD 00 00, profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:02, destinationEndpoint:01, options:0040, messageType:00, dni:71A6, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:FD, direction:00, data:[00]]

dev:892022-04-23 03:54:25.293 pm debugrestarted debouncing timer 1500ms for button 2 (lastButtonNumber=2)

dev:892022-04-23 03:54:25.272 pm warnignored event for button 2 - still in the debouncing time period!

dev:892022-04-23 03:54:25.270 pm debugcatchall descMap: [raw:catchall: 0104 0006 02 01 0040 00 71A6 01 00 0000 FD 00 00, profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:02, destinationEndpoint:01, options:0040, messageType:00, dni:71A6, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:FD, direction:00, data:[00]]

dev:892022-04-23 03:54:24.464 pm infobutton 2 was pushed

dev:892022-04-23 03:54:24.462 pm debugcatchall descMap: [raw:catchall: 0104 0006 02 01 0040 00 71A6 01 00 0000 FD 00 00, profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:02, destinationEndpoint:01, options:0040, messageType:00, dni:71A6, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:FD, direction:00, data:[00]]

dev:892022-04-23 03:54:24.167 pm debugsendEvent [name:battery, value:100.0]

dev:892022-04-23 03:54:23.971 pm debugdebouncing timer for button 1 expired.

dev:892022-04-23 03:54:22.454 pm infobutton 1 was pushed

dev:892022-04-23 03:54:22.452 pm debugcatchall descMap: [raw:catchall: 0104 0006 01 01 0040 00 71A6 01 00 0000 FD 00 00, profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:71A6, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:FD, direction:00, data:[00]]

dev:892022-04-23 03:52:35.064 pm debugdebouncing timer for button 2 expired.

dev:892022-04-23 03:52:33.569 pm debugrestarted debouncing timer 1500ms for button 2 (lastButtonNumber=2)

dev:892022-04-23 03:52:33.548 pm warnignored event for button 2 - still in the debouncing time period!

dev:892022-04-23 03:52:33.546 pm debugcatchall descMap: [raw:catchall: 0104 0006 02 01 0040 00 71A6 01 00 0000 FD 00 00, profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:02, destinationEndpoint:01, options:0040, messageType:00, dni:71A6, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:FD, direction:00, data:[00]]