number3 schreef op dinsdag 12 januari 2021 @ 22:05:
[...]
De commando's worden nu verstuurd (heb je goed gezien) en nog niet bevestigd. Dat staat op mijn todo lijstje, ik zit eraan te denken om een soort van "retry" API / MQTT commando variant te maken. Dat ie het bijvoorbeeld 3 of 5 keer probeert met een kleine vertraging.
Wat vindt je daarvan?
En dan 1duidig terug te koppelen wat het effect was in een ander topic. REST API wordt wat ingewikkelder, want je kan niet bv. 10seconden wachten (3 retries).
Dan kan je je scripts om de boel aan te sturen eenvoudig houden en doet de ESP8266 het werk.
Ik was zelf aan het bouwen in die py lib met een reply-check en max retry of max-time in de instellingen van de lib, niet al optie voor een topic. Maar je idee van een gescheiden topic voor 1x cmd of een retry cmd is niet eens zo slecht

Ik kan me echter geen concrete functie voorstellen voor een opstelling waarbij cmd bevestiging niet gewenst is.
Ik zou niet direct gaan voor 3x of 5x een command sturen. Mijn gevoel is, puur gevoel - geen verdere onderbouwing, dat het beter is niet in bursts te schieten omdat volgens mij de seriele bus gewoon al erg druk is op het moment er niet met het PS=1 commando gewerkt wordt. Dus in dat geval zou mijn voorkeur zijn om 2 settings te hebben:
- command_max_retry [int > 0]: aantal x dat er gebeurt wordt voordat een failure gerapporteerd wordt. (1= cmd wordt 1x verzonden, 3 = cmd wordt in totaal 3x verzonden)
- command_confirm_wait [int >= 0]: wacht tijd in [s] op een command bevestiging, 0 is dus effectief niet wachten op een confirm. > 0 is wachten op een confirm, error rapporteren als die niet ontvangen wordt binnen de tijd.
dus retry=0 en wait=0 is fire & forget (huidige
retry=3 en wait=3 is fire, wacht 3s, fire nogmaals , wacht 3s, fire 3e keer, wacht 3s, error rapport
Ik post nu zelf de status van een verzonden command naar een apart topic bv:
- base = otgw/
- commands: otgw/set/<command>, bv otgw/set/room_temperature/temporary 19.50
- command feedback: otgw/cmd_feedback/room_temperature/temporary, payload: <int> bv dus 19.50 als het bovenstaande command bevestigd wordt
--- of bij error posten naar otgw/cmd_feedback/room_temperature/temporary/error, payload <char> bv dan MAX_RETRY.
Nu ik dit schrijf zit ik te bedenken waarom ik niet met het PS=1 command werk, dus polling ipv alles maar door otgw laten pushen ....

hmm, heb ik eigenlijk niet direct een argument voor
Mijn originele reden om niet de HA integration te gebruiken was de data resolutie: er werd naar mijn idee niet vaak genoeg data opgehaald/doorgestuurd naar recorder voor wat ik prettig vind.
[
Voor 3% gewijzigd door
sjorsjuhmaniac op 12-01-2021 22:48
]