Do you really need to record and replay, if you can get away with designing the schedule rather than recording then there are much simpler solutions. node-red-contrib-cron-plus for example.
Interesting use-case. Possibly a little over-thought
Most of us just use static schedules whether we are at home or away. Having a light on at all will deter most burglers. Having one that switches on when it gets darker may save you a little money.
If you want to go that way though, what you are really doing is creating a FIFO queue for each light. Not aware of anything that will do that for you. Not very hard to create though using a function node. You might want to look at the uibuilder WIKI which has a caching example that you could easily adapt.
One thing you might want to do extra though is to limit the amount of storage used.
Yes, I'd like to. Plus it would be a cool feature with lots of uses for all sorts of people, wouldn't it?
Storing human-activated state changes would be useful in producing (like machine learning) predictive automated state changes, e.g. learning how you use heating, lighting, etc and making those decisions for you or, at least, suggesting them or popping up the most appropriate tab on the dashboard UI, before you even think of it
Using cron is fine, but I'd want to populate it with real-world data from my actual usage. I specifically want a replay (or flow output) that is genuinely random and not routine over any sub-interval, e.g. day - so all the days are different and look human activated.
What I have done in tha past is just create a simple timestamped log file of MQTT activity...
timestamp#topic#payload
then I created a replay node that read that file and just replayed the topic and payload using the timestamp differences to do necessary.... but I was just replaying arbitrary data - whereas you would want to re-sync the hours to be approximately right (otherwise you have to start replay at exactly the correct time of day
Whilst this is interesting from a theoretical viewpoint, I don't see it as adding much value from a practical one unless you know for sure that you are likely to be actively surveiled over a period of time. Even then, you would need to be thinking about a lot more than just lights. What about the presence/absence of vehicles, curtains/blinds, heating, TV and other sounds?
Truth is that most burglaries in most places are opportunistic. Where active targetting is happening (and I've seen this with a colleague's house), the attackers may not even care whether someone is in the building or not. But either way, in those cases, a response to activity is much more effective. So turning on additional lights based on movement or noise. Also creating noise is effective - either an alarm or dog barks.
@dceejay it's a custom solution which I'm fine writing/curating but was hoping to reuse an existing node or flow. If you can share the flow that would be really helpful ) but if you've not got it, a pointer to the standard nodes needed would be a good start.
Did you write to a file on the underlying OS filesystem? Was thinking a global array would be easier to access and manipulate from nodes.
Very good points @TotallyInformation and I like the idea of active responses (I had a similar function where one PIR would turn on specific extra lights depending upon the sequence of PIRs activated)
They are additive though (and I will look at adding them) but would enhance a generic replay solution, rather than a manually created schedule.
