Overnight Shift Schedules

An issue that some of our sites encountered is the lack of capability to set up a production shift that is starts on one day and ends the next (night shift). Is this feature being worked on to allow for greater flexibility to capture overnight shifts in a cleaner way other than splitting it up? (see attached)

Ex. Shift Start 6:30pm - Shift End 6:30am

Hi Alec, this is a great suggestion. We know about a number of situations that do not fit well into the current Shifts and Schedules feature. This is a good example.

We are looking to do a full rebuild of the feature to capture all the variants that we know about. I don’t have a timeline for you yet. But for the time being, your approach is the best way to handle this situation.


We came across this today :slight_smile: Is the rewrite still in the works :slight_smile:


All a shift calculation really is is a lookup function based on day of week and time of day to some text based output. I wonder if this is really something that could just live as a custom expression (Thread 1, Thread 2) instead of trying to create an isolated, unique part of the platform.

I worked around this for machines using a Node Red flow that does the lookup from a table (in Tulip BTW) and then publishes the result to a MQTT Broker. I then pipe in in through Kepserver and map it to a machine attribute I record on state change.

That way I can do all my analytics by shift which is a requirement for us.

For applications I started with a connector function that returns the last 3 shifts (including the current). If I only need the current shift I just use a table aggregation.


Thanks for your input / workaround here @Richard-SNN !

@mellerbeck @danielpomeranz @alec.giljohann - Just to be fully transparent, the rewrite on the schedules & shifts feature is likely far out due to other priorities.

That being said, I think Richard’s suggestion is a good one, and perhaps another thing that may help is using Automations (Schedule a task to update a table field with the current shift) which would be more reusable than a bunch of triggers across your apps. You can actually see an example of this from @Amit in his post Automation using expression with dates

Thanks for the reminder! I need to reevaluate the solution once we upgrade to LTS 12.