why use backlog???
Closed this issue · 5 comments
Hi
I was wondering the otherday why we use the 'backlog' command in the tasmota update?
we could simplify the setup and use
update:
smartthings/cmnd/iFan03/STATUS:
command:
'refresh': '0'
this lets the device flood the MQTT queue with extra info but we still decode it fine.
it then becomes easy to pull extra info if we so desire.
just a thought.
This was a lot of optimization I had to do. If u do status 0 - tasmota sends 11 separate MQTT commands which mean 11 separate commands to the app and from the app to the device. Every time the app calls the device in the device activity log an activity event is published - app sent command processmqtt to device
There is no way I can hide that from the interface - and it is plain ugly. That is why except for LWT I do not subscribe to any auto updates from tasmota - I have to manually click refresh - otherwise your activity log will be filled with useless app called device messages and the really useful action Command like on or off will be sporadically somewhere in this middle - so if u really didn’t care about status updates every 5 minutes but just wanted to review device events very inconvenient - so I made a compromise Of 4 calls for a manual refresh so there is still some sanity - would have love to auto update status more frequently but ST suckS in this
Also remember more overhead at server, on the network and the app/decide for every unnecessary message that u r sending over - even with these 4 calls refresh takes a few seconds and the state object is getting corrupted states.
I am looking to improve server side performance issues next but very limited things I can do with STs limited access for smart apps. Like I wondered if I should update status every hour but then again useless messages - and after the initial state I found I was happy with hitting refresh if I wanted updated status except of course if device goes offline then u want to know that as soon as possible
Point taken!
though what you did just make me thing was if you had the MSB server at the time it has all the resubscribes, it then does a send of all the update commands. That would issue the command for any device which has an update commant in the Devices.yml. Then in ST, these commands are automatically processed. That could give you your refesh.
Maybe not on that frequence by on the resubscribe at midnight.
i was thinking about what you said and I think I am a little confusted...
yes Mosquitto gets 11 messages returned and yes the bridge sees the messages, BUT you are only subscribed to the messages you want so the bridge ignores anything else. The redundant ones, wont be processes and shouldnt appear in the activity log.
BUT maybe it depends on the system you have for the bridge... Im sitting on ubuntu on a virtual machine on an HP micro server with a Xeon processor! I've got a stupid amount of processing power!
no you are right the subscribe topics will ignore the ones that we don't subscribe. I thought you meant do status 0 and let all messages come all the way through.
Any way I needed to pull name and friendly name - they come with status.
status 0 gets status 1-11 but not status.
you would need to run two commands any way. Not worried about horsepower but more about minimizing load on the devices as at least before when i was having issues with the firmware this flood of messages was causing device to reboot - so definitely load avg on device increases.
but for now i would need Status and status 0 - and just chose to be more specific.
by default tasmota sends tele/stat command every 5 minutes and LWT to at some predefined interval
Just FYI - making small upgrades to the Smartapp - mostly new additional incremental functionality as needed. Have not posted these to github yet as testing for a few days in my environment
2 that might be of interest
- In actionOnOff add conditions for togger so for switch you could send on/off/toggle
- In version 1.0 if server sent duplicate mqtt message i ignore - but special situation where you might need constant polling or status update - so for capability map if you define "duplicate" as key it will allow duplicate messages from the server only for now - still forcing ignore of all duplicate events for ST - can't think of a use case for that right now.