DOF ScheduledSettings (day and night modes)

[rambo3]

DOF now has support for custom day and night modes through three classes: ScheduledSettings, ScheduledSettingDevice, and ScheduledSetting. This is a software approach to having lights or outputs adjusted on-the-fly during different times of the day.

As always; backup your entire DirectOutputFramework - directory before toying with this ! I take no responsibility for issues, fire, damages, earthquakes etc.
https://github.com/rambo3/DirectOutput/tree/ultimateio/DirectOutput/Builds

Swisslizard: huge thanks for putting the project on GitHub. This project, like Philips Hue support, is not official but a side project off the original R3.

Introduction
As I got home from the job tired I wanted to play pincabs with less noise or brightness. I was changing the Cabinet.xml, renaming files to shut off the contactors, powering off the RGB or using alternative fade curves. At one point I started experimenting with overriding DOF output strength through Cabinet.xml and just brute force code, and eventually the XML settings got to a point that I could have full brightness on everything during the day, gradually shut off contactors, and adjust the Teensy brightness at midnight. Changes would kick in during a game and over midnight, which initially seemed like a bug where contactors would suddenly no longer "work".

This is a software approach to specific devices in DOF for dynamically adjusting custom outputs, including Teensy brightness for individually adjustable RGB strips which by default are very powerful.

Setup
Add the following to your Cabinet.xml, say just before </Cabinet> at the end of your XML, and start adjusting / removing. The example below goes into effect 2200-0500, sets my contactor specific outputs to off, adjusts the Teensy back LED-matrix to 30%, and shuts off the SainSmart USB outputs. And it's enabled.

<ScheduledSettings>
	<ScheduledSetting>
		<Name>Night Mode</Name>
		<Enabled>true</Enabled>
		<ClockStart>2200</ClockStart>
		<ClockEnd>0500</ClockEnd>
		<ScheduledSettingDeviceList>
			<ScheduledSettingDevice>
				<Name>Ultimate I/O contactors</Name>
				<ConfigPostfixID>27</ConfigPostfixID>
				<Outputs>49,50,51,52,53,54,55,56,57,58</Outputs>
				<OutputPercent>0</OutputPercent>
			</ScheduledSettingDevice>
			<ScheduledSettingDevice>
				<Name>Teensy LEDs back matrix</Name>
				<ConfigPostfixID>30</ConfigPostfixID>
				<Outputs>1</Outputs>
				<OutputPercent>30</OutputPercent>
			</ScheduledSettingDevice>
			<ScheduledSettingDevice>
				<Name>Sainsmart USB</Name>
				<Description>Note that the Sainsmart is a 0/1 relay array and that 0=off while 1-100 is considered on. There is no inbetween, a relay is either open or closed ("bitbang").</Description>
				<ConfigPostfixID>40</ConfigPostfixID>
				<Outputs>1,2,3,4,5,6,7,8</Outputs>
				<OutputPercent>0</OutputPercent>
			</ScheduledSettingDevice>
		</ScheduledSettingDeviceList>
	</ScheduledSetting>
</ScheduledSettings>

Settings
<ScheduledSetting> is a mode containing start-end time of effect, enabled state, device list. You can have multiple <ScheduledSetting> objects to specify morning, daylight, evening, midnight. Times are forward-looking; typing 2050-0800 would literally mean from 2050 and until 0800 in the coming morning.
<ScheduledSettingDeviceList> contains all the devices you want to affect.
<ScheduledSettingDevice> is a single device, its outputs (according to configtool) to affect, and the output strength in percent 0-100. To let DOF know which device you want to control, match the ConfigPostfixID with your configtool ini file, for instance directoutputconfig27.ini with 27 being the postfixid.

Passing midnight
The settings have been confirmed to work passing midnight, which initially was a real problem practically and technically. There's an interesting issue here when a range passes to the next day (2300-0300 for instance), idea being schedules should be able to run all day long in real time without reboots. It's important checks are done in real time, not at DOF boot, as it probably wouldn't become active again if a pincab was online more than a day.

Debugging
Check your DirectOutput.log file for details if nothing works.

Device support
Currently Ultimate IO, SainSmart, Teensy and Philips Hue are fully supported. PacLed64, PacDrive and LedWiz have the support added in, but since I don't have those devices I can't confirm that they actually work. Note that the switches / relays like Sainsmart USB device is a 0/1 relay array and that 0=off, while 1-100 is considered on. There is no inbetween, either open or closed ("bitbang").

 

Gotta run real quick for work; hopefully this post doesn't have too many errors, I'll recheck after work.

 

[Ginsonic]

Many thanks for your great work Rambo3, much appreciated ! 

[Thalamus]

Very cool - thank you !

[KiwiBri]

This looks great.. Will we be able to turn off certain toys based on tables?

Sent from my SM-G935W8 using Tapatalk

[rambo3]

No, but that's actually a great idea. Any suggestions on how you'd want something like this implemented, or what you'd need? The <ScheduledSetting> is a background thing running continuesly, but something like <TableSettings> could work?

Right now I'm thinking something with Name, Enabled, Table name (not sure; filename? rom?), and the devicelist similar to above. It'd be nice to have day/night-modes run simultaneously. That should make it possible to not only turn off stuff on a per-table basis, but set a strength property to some toys like lights.

Eh...suggestions?

[rambo3]

Wait a minute; can't you disable toys manually in configtool on a table-basis, specific to your configtool account? 

[KiwiBri]

Wait a minute; can't you disable toys manually in configtool on a table-basis, specific to your configtool account? 

I'm not sure. I'm a noob with DOF.. Lol. I just got the 5 rgbs and strobe working last week and last night figured out how to enable it in PBX. I also got one led strip working. I wish I had come to this forum first rather than that other one [emoji12]


I was thinking of along the lines of turning off led strips for maybe older EM games.. Or maybe they are not defined for those tables anyway? But if you can do it on a table basis that could work too.

I still have to work out how to use the DOF configuration tester exe. [emoji1]

Sent from my SM-G935W8 using Tapatalk

[arngrim]

Wait a minute; can't you disable toys manually in configtool on a table-basis, specific to your configtool account? 

euh no sorry

Envoyé de mon SM-G800F en utilisant Tapatalk

[rambo3]

Allright then, I think I have something to work on. I'm kind of in the "DOF"-mode these days.

Experimented yesterday with capturing and testing the latency of my UIO -> Sainsmart --> contactor signal delay by basically capturing the devices inside the pincab at 60FPS. You can see when an output gets triggered (LED on Sainsmart), and when a contactor pushes and releases. A full cycle was about 180ms, with the Sainsmart at ~100ms, contactor ON ~34ms, contactor OFF ~46ms rougly. It hit me that if the left flipper was triggered twice within say 100ms and the primary contactor was still busy processing, why not offload retrigger to the slingshot contactor sitting right beside it? Basically have another output assist a running output while the first one was still running as a way of compensating for slow hardware. It worked quite well practically, sounded a bit funny due to different contactor assisting on quick retriggers, but then realised that the real problem of course was the Sainsmart itself; 100ms before reaching the contactor is alot.

I'll do some experimenting in a few hours with the disable-toy-feature and report back!

[rambo3]

Just added support for overriding outputs per table, globally, or using wildcards for ROMs and table filenames (either, or both). Outputs can be anything from 0-100 with 0 being turn off, and 100...not making much sense but it's there for consistency. Right now I've got left and right flipper contactors globally shut off, and undercab light at full strength + overcab light completely off for Bad Cats (ROM name "bcats*" with wildcard at the end). Also experimented with undercab at 20-50% strength, and individual R, G, B strength offsets which gave me a nice green color instead of orange in Bad Cats to prove that individual channels were indeed affected  That should pretty much cover it.

Need to do some more testing before putting up a new thread for <TableOverrideSettings>, hopefully tomorrow.

 

EDIT: EM tables don't have ROMs, right? They're basically analog? In this case, I think we got that covered too as a <Roms> being blank instead of something like "afm" (Attack from Mars) could in effect be triggered to say disable LED strips.

[Thalamus]

Yes. EM doesn't have roms, but, I believe that the tables are given a rom name never the less in order to work with DOF. Or, maybe it was another parameter, Sigh, I'm getting old and I just went to bed turning off my cab so I can't verify. Have a peek youself at Diablo, Stranger Things or some of Loserman' tables. Most of these have DOF and are EM or Originals.