Timer stop counting down occasionally about node-red-contrib-mytimeout HOT 30 CLOSED

Do you know what version you have? I'm currently run on 2.1.4 (2.1 was a huge change form 1.x.x but 2.1.x+ mostly has some minor changes for testing and updates to the document). I'll branch my code for a fix and run your flow there.

from node-red-contrib-mytimeout.

Okay, I've found I don't have some of your nodes. So you might need to explain a bit what it is doing. I have noticed that you are setting the msg.timeout. I using msg.payload.timeout (I send the payload via mqtt).

from node-red-contrib-mytimeout.

Hi, thanks for the quick reply.. I'm using Hass.io with Node-red and your version 2.1.4 ... the below image is showing a bit of the approach

I have several lights in my house which are triggered by motion sensors... than i tickle your timer and switch the light off as soon the timer has completed

the node sequence is:

1. select what light to switch on
2. use HA node to switch-on the light
3. reading a global variable which I use to keep the duration dynamic (can be selected by input_select)
4. I have added a telegram node to send a log when light is turned on (does not impact the issue and can be ignored
5. setting / tickling your timer (the below timer display halts frequently)
6. proceed only when the timer went "off"
7. select what light to switch off
8. use HA node to switch-off the light
9. check if telegram-logging is enabled
10. send telegram

from node-red-contrib-mytimeout.

Not sure why the close (or what that means) but I'll keep looking into this. I know that earlier versions when the input had errors I was seeing the updates suddenly just no longer update.

from node-red-contrib-mytimeout.

Can it be because I have several timers in parallel ?? ... Maybe they do impact each other?

I tested the sequence for a while with 1 light and 1 timer and could not see the issue.

In my case I have dedicated a msg input (always the same, set just before the timer) .. so there should not be an input-error .. I can do a delete msg before setting the new input parameters, to ensure no wrong parameters are getting into the timer.

Great work on this ... and thanks a lot for the quick response

from node-red-contrib-mytimeout.

YW, I hadn't given it a try with 2 at once. I can do that. I have a test bed with 4 timers. I can run them at the same time and see the results. Then try mixing. Let's see how that works.

from node-red-contrib-mytimeout.

I think I have about 12 individual timers running at any point of time .. and they are getting tickled/restarted and stopped randomly (e.g. motion, door closed,etc) .. maybe they do impact each other (e.g STOP command to timer5 is putting timer2 on halt)

from node-red-contrib-mytimeout.

I haven't setup the 12 timers yet, but I wonder if having them the same name (Timer) is causing it an issue. They are in the same flow. The name space part of node-red/javascript does confuse me

I'll setup the 12 timers later tonight with a test script and then proceed to abuse it. I'll start out with the same name and set the timers to 90 seconds. I may also add a debug flag so I can easily turn off the log messages. That might be putting too much of a load on the machine. At the moment this is just guessing.

from node-red-contrib-mytimeout.

from node-red-contrib-mytimeout.

Cool, I'll still test this to find out why it might occur but it's good you can use the work around. Testing 12 flows simultaneously is a bit tough to figure out. I think I have a shell script that I can test with.

from node-red-contrib-mytimeout.

I've attempted to test with all 12 nodes being fed by the same input topic (with each output on it's own topic). Not seeing the issue yet. So I'll now move on to each timer getting it's own input as well as output and start sending the more complex input (each timer getting it's own json and hope I can randomize it to some extent).

Also posted a question on Discourse for Node-Red and the folks there have given me a few pointers. I'll work on there suggestions after a bit more testing.

from node-red-contrib-mytimeout.

from node-red-contrib-mytimeout.

Understood, but I'm stubborn, the thought of a bug in my code haunts me ... and I'm fixing it so my wife never finds out about the bug because the timers didn't work. Guess which one is more likely? ;-)

This one appears to be a coding issue with my use of locals instead of globals. The various language scope still confuse me.

from node-red-contrib-mytimeout.

Hi,
I have now 2 Node-Red installations running:

1. Hass.io & Node-Red (with previous version of myTimeout) ==> working
2. Dedicated Node-Red (with latest version of myTimeout) ==> System freezes when timer is started

I installed the 2nd Node-Red system to improve the overall performance and remove some dependencies. It has the basic Raspbian+Nodered installation and all flows are migrated from first system.

After installation everything worked great. Until evening, than suddenly the Node-Red system was suddenly frozen.

• I was able to login via SSH
• Node-red did not respond on events of via web-interface
• the command Node-red-stop than Node-red-start sometimes helped resuming service but not all the time (often I had to reboot)
• I installed the system 3 times because I assumed the SD cards had problems but always had the same issues

Because this drove me crazy, I decided to ignore the issue for a bit and do some new components for my light control. Doing so I was using your timer and realized that the system got frozen almost always when starting your timer.

In the sample above, the timer will start an countdown when clicking the first (upper) inject, but when clicking the 2nd (lower) inject the system is freezing. ==> By removing the timer-component the flow works fine.
[ { "id": "9d14f70.7b28e08", "type": "link in", "z": "6305898b.18bcb8", "name": ">>TS Light ON -now", "links": [], "x": 215, "y": 80, "wires": [ [ "251a0503.a90c7a" ] ] }, { "id": "251a0503.a90c7a", "type": "change", "z": "6305898b.18bcb8", "name": "ON", "rules": [ { "t": "set", "p": "payload", "pt": "msg", "to": "true", "tot": "bool" } ], "action": "", "property": "", "from": "", "to": "", "reg": false, "x": 590, "y": 120, "wires": [ [ "c442f9af.620098" ] ] }, { "id": "ed1f2102.6647f", "type": "time-range-switch", "z": "6305898b.18bcb8", "name": "evening", "lat": "-33.6988083", "lon": "150.8677305", "startTime": "sunsetStart", "endTime": "sunrise", "startOffset": "", "endOffset": 0, "x": 340, "y": 120, "wires": [ [ "251a0503.a90c7a" ], [] ] }, { "id": "c442f9af.620098", "type": "ui_switch", "z": "6305898b.18bcb8", "name": "", "label": "TS Light", "group": "9d457733.6c0608", "order": 0, "width": "3", "height": "3", "passthru": true, "decouple": "false", "topic": "", "style": "", "onvalue": "true", "onvalueType": "bool", "onicon": "", "oncolor": "", "offvalue": "false", "offvalueType": "bool", "officon": "", "offcolor": "", "x": 720, "y": 160, "wires": [ [ "d87568b7.b132f8" ] ] }, { "id": "c2bcd291.a2ae4", "type": "switch", "z": "6305898b.18bcb8", "name": "on ?", "property": "payload", "propertyType": "msg", "rules": [ { "t": "eq", "v": "off", "vt": "str" }, { "t": "eq", "v": "on", "vt": "str" } ], "checkall": "true", "repair": false, "outputs": 2, "x": 470, "y": 160, "wires": [ [ "251a0503.a90c7a" ], [ "623bf9c.cbd7d08" ] ] }, { "id": "f6be8b0b.8ef308", "type": "inject", "z": "6305898b.18bcb8", "name": "", "topic": "", "payload": "", "payloadType": "date", "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "x": 440, "y": 60, "wires": [ [ "251a0503.a90c7a" ] ] }, { "id": "4f06e5de.544a4c", "type": "link in", "z": "6305898b.18bcb8", "name": ">>TS Light ON", "links": [ "b7db86a2.99f5e8" ], "x": 215, "y": 120, "wires": [ [ "ed1f2102.6647f" ] ] }, { "id": "d87568b7.b132f8", "type": "switch", "z": "6305898b.18bcb8", "name": "on ?", "property": "payload", "propertyType": "msg", "rules": [ { "t": "eq", "v": "1", "vt": "num" }, { "t": "eq", "v": "0", "vt": "num" } ], "checkall": "true", "repair": false, "outputs": 2, "x": 850, "y": 160, "wires": [ [ "d5cd39e6.3831c8" ], [ "28a5d4e4.c46cec" ] ] }, { "id": "623bf9c.cbd7d08", "type": "change", "z": "6305898b.18bcb8", "name": "Off", "rules": [ { "t": "set", "p": "payload", "pt": "msg", "to": "false", "tot": "bool" } ], "action": "", "property": "", "from": "", "to": "", "reg": false, "x": 590, "y": 200, "wires": [ [ "c442f9af.620098" ] ] }, { "id": "7f9ca3a9.e7082c", "type": "api-current-state", "z": "6305898b.18bcb8", "name": "?", "server": "2415aba8.2d71f4", "halt_if": "", "override_topic": true, "override_payload": true, "entity_id": "light.ts", "x": 330, "y": 160, "wires": [ [ "c2bcd291.a2ae4" ] ] }, { "id": "d5cd39e6.3831c8", "type": "change", "z": "6305898b.18bcb8", "name": "TV Light timer", "rules": [ { "t": "set", "p": "timeout", "pt": "msg", "to": "TV_Light_timer", "tot": "global" }, { "t": "set", "p": "payload", "pt": "msg", "to": "ON", "tot": "str" } ], "action": "", "property": "", "from": "", "to": "", "reg": false, "x": 1000, "y": 140, "wires": [ [ "6de07a2a.3eba74" ] ] }, { "id": "28a5d4e4.c46cec", "type": "change", "z": "6305898b.18bcb8", "name": "TV Light timer", "rules": [ { "t": "set", "p": "timeout", "pt": "msg", "to": "TV_Light_timer", "tot": "global" }, { "t": "set", "p": "payload", "pt": "msg", "to": "OFF", "tot": "str" } ], "action": "", "property": "", "from": "", "to": "", "reg": false, "x": 1000, "y": 180, "wires": [ [ "6de07a2a.3eba74" ] ] }, { "id": "bf851120.9899", "type": "link in", "z": "6305898b.18bcb8", "name": ">>TS light Off", "links": [ "91042201.9a197", "ded16ced.e18f" ], "x": 215, "y": 200, "wires": [ [ "623bf9c.cbd7d08" ] ] }, { "id": "be1ff681.46fcd8", "type": "inject", "z": "6305898b.18bcb8", "name": "", "topic": "", "payload": "", "payloadType": "date", "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "x": 440, "y": 240, "wires": [ [ "623bf9c.cbd7d08" ] ] }, { "id": "14f58e22.b6b032", "type": "link in", "z": "6305898b.18bcb8", "name": ">>TS Light toggle", "links": [ "10752401.66855c" ], "x": 215, "y": 160, "wires": [ [ "7f9ca3a9.e7082c" ] ] }, { "id": "6de07a2a.3eba74", "type": "mytimeout", "z": "6305898b.18bcb8", "name": "timer", "outtopic": "", "outsafe": "on", "outwarning": "Warning", "outunsafe": "off", "warning": "5", "timer": "30", "repeat": false, "again": false, "x": 1170, "y": 160, "wires": [ [ "4e8a14d4.62d11c" ], [] ] }, { "id": "4e8a14d4.62d11c", "type": "switch", "z": "6305898b.18bcb8", "name": "on ?", "property": "payload", "propertyType": "msg", "rules": [ { "t": "eq", "v": "on", "vt": "str" }, { "t": "eq", "v": "off", "vt": "str" } ], "checkall": "true", "repair": false, "outputs": 2, "x": 1310, "y": 160, "wires": [ [], [ "91042201.9a197" ] ] }, { "id": "91042201.9a197", "type": "link out", "z": "6305898b.18bcb8", "name": "TS off - now", "links": [ "bf851120.9899" ], "x": 1415, "y": 160, "wires": [] }, { "id": "9d457733.6c0608", "type": "ui_group", "z": "", "name": "All Lights", "tab": "99fcea13.c6aec8", "disp": true, "width": "6", "collapse": false }, { "id": "2415aba8.2d71f4", "type": "server", "z": "", "name": "Home Assistant", "url": "https://tsprivate.duckdns.org", "pass": "Thomas@2018" }, { "id": "99fcea13.c6aec8", "type": "ui_tab", "z": "", "name": "Lights", "icon": "dashboard" } ]
I did remove all your timer from the 2nd system yesterday afternoon and the system had no issue since.

I think there is a bug in your latest release...the previous version (which is still running on 1st system) works better for me.

I hope this feedback helps you .. your timer is still the best approach I have found.

from node-red-contrib-mytimeout.

from node-red-contrib-mytimeout.

The stable version in 1st system is 2.1.4
The unstable version in 2nd system is 2.1.8

I just did a complete new install for 2nd system ...all flows migrated from 1st to 2nd .. the systems are now identical

Error-situation:

• Motion detector is triggering light on
• I can see the timer starting
• any other tickle to the timer makes the system freeze (i tried with off command)

I tired Mitigation 1:

• removing all timers and replaced them with normal delay
• all works, no freeze

I tired Mitigation 2:

• I have all light-controls in a dedicated flow
• I disable the light-flow tab
• motion triggers are still detected but no light activities
• all works (without the lights)

I hope you can replicate the situation and i helps solving the issue

good luck

from node-red-contrib-mytimeout.

Feature request:

I usually need a decision node after the timer to evaluate the msg.payload for "on" or "off"

Would it be possible to have optional out-ports for on and off.. in addition to your current out-port ?

from node-red-contrib-mytimeout.

For the feature request, I think a switch node would be the correct choice. I'm not even sure how I could work that feature into the existing code.

BTW, I also turned off (by default) all the debugging code. A check mark in the node config will turn it on for each node. I'm wondering if that code is at the source of the issue. I'll see shortly.

from node-red-contrib-mytimeout.

I have done a few more test .. and it looks like when I start the timer and let it run till the end without any further trigger (On/Off/new time) ... than everything works

It is only when I tickle/trigger the timer again that everything is freezing

from node-red-contrib-mytimeout.

Thanks for the help. I've tried the latest mytimeout on one of my Pi look a-likes (need to find the stuff for a Pi setup. I have:

18 Aug 19:19:43 - [info] Node-RED version: v0.19.1
18 Aug 19:19:43 - [info] Node.js version: v8.11.4
18 Aug 19:19:43 - [info] Linux 3.8.13.30 arm LE

Installing module: node-red-contrib-mytimeout, version: 2.1.8

I setup a timer with one injection and one debug. It works with on and let run & on - on - on and it works. I'll try some more. Can you do the following:

sum mytimeout.js # for both 2.1.4 and 2.1.8

I'm dropping in your flow from above and I'll try that out also.

from node-red-contrib-mytimeout.

from node-red-contrib-mytimeout.

Sorry, those are Linux commands, so you'd run them from the command prompt. As the user who started nod-red do (command line/command prompt):

cd ~/.node-red/node_modules/node-red-contrib-mytimeout
sum mytimeout.js

On a side note, I ran your code above. I am missing the time range and the light state node but I don't think they're needed for this test.

When I finished the setup I notice that the 'flows' stop because the lack of a server setting

18 Aug 19:53:47 - [info] Waiting for missing types to be registered:
18 Aug 19:53:47 - [info] - server
18 Aug 19:54:48 - [info] Stopping flows

I don't know what this means at this point but I'll search for that. I don't think that is related to mytimeout. It may be related to my current setup.

from node-red-contrib-mytimeout.

Okay, fixed that, needed to remove an unknown node under the configuration node. And with that ...

WOW, you broke it! ;-) I'm able to reporduce the issue you ran into. It's locked up. Let me see what I can find.

from node-red-contrib-mytimeout.

Okay, I know exactly what is going on. Your basically feeding the output to the timer to the input of the timer. This feedback is keeping NR so busy that NR can't respond. There was a change between 2.1.4 and 2.1.5 that made to handle this differently. I'll need to have a good look at this. Not sure how to handle this. The problem with 2.1.4 is that if you sent on On and several days later sent another On then the 2nd On gets dropped (probably indefinite hold of the last message sent).

from node-red-contrib-mytimeout.

Next question, do you intend to continuously send the commands back into the loop?

from node-red-contrib-mytimeout.

Damn, yes you are right .. I created a loop for the off command :( .. no, that was not intentional

I created the loop to update the dashboard-ui button to OFF when the timer completed :( .. I will have to change that code.

Thanks for helping with my issue that fast

from node-red-contrib-mytimeout.

I think you can add a delay note, set it to rate limit, 1 msg / 1 second and drop immediate messages. Add it to the link in @ts Off. I think that should work. I think the reason mytimeout node isn't handling it is because the case of the message changes. the node sends off and the incoming is set to OFF. I'll see about adding a case insensitive option. Need to give that some thought.

from node-red-contrib-mytimeout.

I will check the current state and will stop the flow if in this case the light is already off.

I don't think there is anything required to be done in your node .. it was my stupid endless loop causing the issue and not realizing it

Update: It works

from node-red-contrib-mytimeout.

The latest code has the msg handling fix and an option to ignore case on input match. This might help a little bit on sedning the output to the input. I tried to handle that issue because it's useful to send the output to the ui_switch so you can match the controlled device's state. I think your code was changing the case so it didn't match. There are some other updates to the code to clean up the handling and some kruft that was in the code. I still need to update the documentation and open an issue on a error message the can be ignored:

"The workspace contains some nodes that are not properly configured: ... are you sure you want to deploy."

You can deploy it's harmless and I have a manual fix but I need to figure out how to word it.

Hopefully I haven't broken anything. My test script passed but I'm noticing that it's coverage is not complete.

from node-red-contrib-mytimeout.

found this while browsing an unrelated bug, what an awesome exchange between you two

from node-red-contrib-mytimeout.