Yep, it seems to be sending status..
Do you see in the Events window which app is sending periodically the on() command?
In my opinion, when a driver command on() is called - it should be executed unconditionally, no matter what switch state the driver 'thinks' it is ... last state may be wrong. So the driver should not filter commands.
4 Likes
I agree
4 Likes
Thanks, but not sure how to fix this issue?
I have removed the plug from the rule and re-subscribed to controller events and it seems to be behaving now.
What do you mean by ‘behaving’?
I mean, the periodic polling has stopped after the device was removed from the rule.
One thing that still confuses me is that I have a 2nd meross plug on another rule and that one does not have this polling issue?
This rule will be triggered with any update of the humidity readings from the bathroom sensor. The rule will turn the plug on every time when a new humidity event above 65% is generated by the sensor..
I think it’s OK as it is.
Yes, this has been working fine and there was there was only 1 hub action for the device compared to 688 hub actions for the other meross plug.
Anyway, I will not use the problem plug for now, thanks.
It is very unlikely that the problem is in the Meross plug...
Are you using one and the same driver for both plugs?
TxCtr (the number of thetransmitted messages) is too high for both devices.,,
I should probably add an auto-reset of the statistics on the HE reboot.
1 Like
Yes, you are correct.
I have now made one minor change to the rule (command only switches that are off) and all is well, rule has been running it for a few hours well, thanks.
1 Like
@kkossev this driver works great, any chance you plan to make an advanced matter driver for switches and dimmers? Pretty Please..LOL
I have no plans for new custom Matter drivers at the moment. These were made with a primary goal to learn about the Matter protocol and the implementation in the HE... I am currently working on a very complex Matter Bridge project, once it is ready for public release I can go back to the dedicated custom Matter device drivers. I should be able to reuse a significant part of the code made for the Bridge project back into the existing and potentially new custom Matter drivers ( adding healthStatus and extra configuration options).
I am curious, what make/model of a Matter dimmer device you have?
2 Likes
I have a bunch of Kasa KP205 on/off and some Kasa KP225 dimmers on the way.
Thanks and I look forward to the bridge integration
1 Like
Just a follow up, installed one of the dimmers tonight. Don't like it, they will be going back. The on/off work good so far. Only thing I've had 2 out of 12 become unresponsive to GH and Hubitat. Had to reset and re-add, not sure why.
1 Like
@kkossev,
I have noticed that I have to ping the meross plug to keep it or bring it online.
Just wondering does the healthcheck not ping the device as well?
Hi @iEnam ,
I looked at the code now - the default healthCheck method in this driver is currently 'Activity check', i.e. the polling is not enabled by default. I will change the defaults in a future update, because the Matter plugs seems to not send any heart-beat messages (unlike the Zigbee plugs). So, the active Ping() method is better suited here.
You can change the healtCheck method manually from the 'Advanced Options'
2 Likes
