Send MQTT message on LastChangeTime change rather than Value/String change

[Loafdude]

Thanks for this plugin Michael.
It works well
I've run into a limitation.

I have homeseer dimmer switches which support multitap payloads.
They send various payloads depending on number of presses on which paddle (1003/1004/1005/2003/2004/2005)

mcsMQTT sends a message the first time I double click the up paddle (1003)
mcsMQTT does NOT send a message the second time I double click the up paddle (1003)
mcsMQTT sends a message if I triple click the up paddle (1004)

Obviously this is by design and works for most cases I understand.
Is there anyway mcsMQTT can send a message on Last Change Time rather than status change?
This would allow me to press the same button repeatedly and get multiple MQTT message.

Thank you!

[Michael McSharry]

I suspect this may be a HS limitation. We need to dig deeper to know for certain. in earlier versions of plugin there was info for when HS informs the plugin of a change. it was chatty and I think I removed it on latest version. I can put it back in later today for our use.

mcsMQTT, as all plugins, ask HS to callback on changes of a device value or device string. If there is no change in either of these then I suspect HS does not inform the plugin. I need to look at API, but I do not remember a callback on last change date.

[Loafdude]

Thanks for taking a look

I was perusing the API. I assume CBs are registered using RegisterEventCB
https://homeseer.com/support/homesee...tereventcb.htm

I see what you mean by limitations on how they are triggered.
The only hope appears to be GENERIC and EV_TYPE_LOG callbacks.

Are you able to rig something up to output logged events from these two callbacks I can test with?

Really appreciate your help!

I'm available anytime

[Michael McSharry]

I have put the plugin .exe file at http://mcsSprinklers.com/HSPI_MCSMQTT_34111.zip.

When debug is enabled it will output each HS callback to the debug .txt file which is in \data\mcsMQTT subfolder. You can assess if callbacks are being generated without a change in value or string, but only update of last change. Note that the SetDeviceValue has a parameter to update the lastchange even if no change in value occurs so clearly this parameter is being set when the paddle is clicked.

The callback mechanism is a little different for plugins than scripts,but the callback enumerations are the same.

[Loafdude]

Thanks for whipping that up so fast!
Unfortunately HS3 does not generate any event on the second press.

I have found a workaround using events.

IF Basement MediaRoom MultiTap just had its value set or changed
THEN Send Mqtt Message Topic "Home/testing" with Payload "$$DVR:(32):" 

This will trigger on repeated button presses.
Too bad HS3 doesn't expose an equivalent callback to plugins/scripts.

Great service on your free plugin Michael.
Thanks for investigating.

If you need testing done in the future feel free to pm me

[polymathcoder]

I just posted something making the same request before seeing this... whoops... That's too bad. I have been using the same workaround via events and was hoping it'd be something that could be added easily to the plugin, but I guess not...

[Michael McSharry]

I do not recall seeing LoadDude's second post before I responded so what he tested with did not have any additional callbacks for Log. Generic callback needs something raising the trigger so it is not appropriate for this situation.

Looks like there is hope that the Log callback can be used for this purpose. I sent two consecutive Off commands and both showed up in the log

Device Control

Device: Rain8 V1 to Off (0) by/from: CAPI Control Handler

Device Control

Device: Rain8 V1 to Off (0) by/from: CAPI Control Handler

I will see what I can do to integrate the Log callback into mcsMQTT

[Michael McSharry]

Implemented the ability to publish based upon a Log callback. Option enabled on the Edit tab for non-plugin devices. The plugin uses the DeviceValue that is reflected in the log entry. Also available in the log is the Label (e.g. On vs. 100). Let me know if the implementation in 3.5.3.0 works for you. It will be in the updater soon or now from http://mcsSprinklers.com/mcsMQTT_3_5_3_0.zip