Not sure if this is possible or not, but I have a lighting controller that I connect and send messages over TCP. It's fairly simple, however, it doesn't handle messages well if they are sent too quickly to the controller. They tend to get dropped. I've implemented a rate limit using the delay node and that ensures that all messages are appropriately handled. One issue is that I run into an issue where I'm getting the status of several lights, but then also sending a request to turn a light on. Turning the light on gets stuck in queue and can take up to 30 seconds to turn on as the rate limit works through the other messages. Is it possible to have the rate limit, but if a specific message with a payload identifier comes in, it now takes priority and goes to the front of the queue, so there is no delay, or negligible delay? I guess clearing the queue would also work as long as it allows the message through to turn the light on.
You could use two rate limit nodes in series with the second one set marginally quicker than the first so that it will generally be empty (as it will not be sent messages at a greater rate than it can handle). Then feed your priority messages directly into the second rate limit node. In that way the controller will still not be overloaded but your prioirty messages will jump the queue of messages waiting in the first node.
Ah, that's a good idea. I'll check it out. I ran a test with inject nodes and it seems to work fairly well. I'll have to check when I get home
The delay/ratelimit node can be configured to work per topic - so if each light has a different msg.topic they can be handled separately via the same node. (as long the controller can handle interleaved commands).
I don't think that will quite do the job, as the priority message could be posted too soon after after a normal message thereby confusing the device.
It can be set to
which will then honour the timings between each topic/message
Thanks dceejay. That won't work. I absolutely need the priority messages to be passed through to the controller. I ran a test using the inject nodes and it's definitely dropping messages. While the first message sent eventually makes it through, if I send each message after the next, any subsequent requests are dropped. If I send them immediately, then I'm sending two messages to the controller which can't seem to handle more than 1 message per 500-700ms. Based on my testing, it looks like Colin's solution is exactly what I need. I'll know more tonight when I can visually see the results and track the logs.
A lot of this would be resolved if I could get the controller to properly communicate when events occur rather than polling for light status, however, my controller is no longer supported. There are several firmware upgrades, but I definitely don't want to brick the device updating it. I also have no clue what each firmware update contains as there is no release documentation that I can find online.
Ah right yes - ok.
Sort of like this
[{"id":"3fe2b4fe.f1137c","type":"inject","z":"3ead5d77.6a6672","name":"","topic":"normal","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":150,"y":340,"wires":[["e2752944.d7aa98"]]},{"id":"e2752944.d7aa98","type":"delay","z":"3ead5d77.6a6672","name":"","pauseType":"rate","timeout":"5","timeoutUnits":"seconds","rate":"1","nbRateUnits":"1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"x":350,"y":340,"wires":[["d2f9b603.16c778"]]},{"id":"d2f9b603.16c778","type":"delay","z":"3ead5d77.6a6672","name":"","pauseType":"queue","timeout":"5","timeoutUnits":"seconds","rate":"1","nbRateUnits":"1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":true,"x":410,"y":400,"wires":[["2c764445.6392cc"]]},{"id":"ff27ae9a.04301","type":"inject","z":"3ead5d77.6a6672","name":"","topic":"high","payload":"Hello","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":160,"y":400,"wires":[["d2f9b603.16c778"]]},{"id":"2c764445.6392cc","type":"debug","z":"3ead5d77.6a6672","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","x":450,"y":460,"wires":[]}]
Sort of yes, the issue is when managing topics the node automatically drops intermediate messages. So if I want to turn on several lights on different loads. I could potentially send 1-5 loads almost all at once, so with your example if you force the injection on the high priority it drops those that are sent too quickly instead of queuing them. This is the suggestion that Colin proposed and it does seem to work.
[{"id":"2565fdf5.4f82a2","type":"tab","label":"Flow 2","disabled":false,"info":""},{"id":"69fc869f.90c358","type":"inject","z":"2565fdf5.4f82a2","name":"","topic":"normal","payload":"","payloadType":"date","repeat":"0.5","crontab":"","once":true,"onceDelay":"0.3","x":150,"y":100,"wires":[["3b8e1aed.d74036"]]},{"id":"3b8e1aed.d74036","type":"delay","z":"2565fdf5.4f82a2","name":"","pauseType":"rate","timeout":"5","timeoutUnits":"seconds","rate":"1","nbRateUnits":"1.1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"x":360,"y":100,"wires":[["faacc777.cbfc58"]]},{"id":"faacc777.cbfc58","type":"delay","z":"2565fdf5.4f82a2","name":"","pauseType":"rate","timeout":"5","timeoutUnits":"seconds","rate":"1","nbRateUnits":"0.6","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"x":450,"y":180,"wires":[["202693d.62f31ec"]]},{"id":"40f59e7e.c0027","type":"inject","z":"2565fdf5.4f82a2","name":"","topic":"high","payload":"Hello","payloadType":"str","repeat":"1","crontab":"","once":true,"onceDelay":"2","x":130,"y":160,"wires":[["faacc777.cbfc58"]]},{"id":"202693d.62f31ec","type":"debug","z":"2565fdf5.4f82a2","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","x":690,"y":180,"wires":[]}]
In the example the queue continues to grow, but in reality that's not the case. But it does appear to allow the higher priority messages to get through within the time frame I'm looking for.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
