In UpdateStatusColour, the code checks to see what state the device it's processing is in and relays that information to the user with a colour change on the dashboard. In a previous commit, I forgot to include a return statement to indicate the Relays (gallery1 and 2) are on. The one line of code added here addresses that.
Note: The code is starting to look sloppy. The code in UpdateStatusColour is beginning to turn into a sprawing mess of branching logic. I have decided to keep like this for now because of the fixed requirements but you should be aware of the mess building-up. If the requirements begin to change, here might be a good place to start refactoring from.
The changes here are a completion of a previous P.O.C. commit. When the program detects a change in the status of a device (I.E. 'on' to 'off' and vice-versa), Eyes and Ears will play an text-to-speech phrase to indicate the change.
This is in aid of providing the user with more feedback about the program (eyes and ears) than the light readings and web requests. The toggle button allows the user to turn-off the logs if they don't want or need them. This is not a full implementation of the logging system (this is just a start).
There was a case where the device status would change to the 'low light detected' (light sky blue) when on the border between a weld being detected and not. This commit addresses that. Also, both Light Meters have been installed at this point and it is apparent both of the welding booths have different light levels. Becuase of this, the dashboard now has code in place which seperates the update-checks to match the device/welding booth. In other words, factory1 does not go dark see green at factory2's light levels.
In UpdateStatusColour, the code checks to see what state the device it's processing is in and relays that information to the user with a colour change on the dashboard. In a previous commit, I forgot to include a return statement to indicate the Relays (gallery1 and 2) are on. The one line of code added here addresses that.
Note: The code is starting to look sloppy. The code in UpdateStatusColour is beginning to turn into a sprawing mess of branching logic. I have decided to keep like this for now because of the fixed requirements but you should be aware of the mess building-up. If the requirements begin to change, here might be a good place to start refactoring from.
The changes here are a completion of a previous P.O.C. commit. When the program detects a change in the status of a device (I.E. 'on' to 'off' and vice-versa), Eyes and Ears will play an text-to-speech phrase to indicate the change.
This is in aid of providing the user with more feedback about the program (eyes and ears) than the light readings and web requests. The toggle button allows the user to turn-off the logs if they don't want or need them. This is not a full implementation of the logging system (this is just a start).
There was a case where the device status would change to the 'low light detected' (light sky blue) when on the border between a weld being detected and not. This commit addresses that. Also, both Light Meters have been installed at this point and it is apparent both of the welding booths have different light levels. Becuase of this, the dashboard now has code in place which seperates the update-checks to match the device/welding booth. In other words, factory1 does not go dark see green at factory2's light levels.
The app. is going to use a date based versioning system going forward. The format is yyyy.mm.dd.build. The build number is the build for that day and not a 'total' build (I.E. the total amount of time the app. has been built).
Note: Visual Studio does not like it when you use '01' (I.E. January). It does not compile because it does not match any reg-ex patterns specified by the UWP. Instead, you must use '1' to represent January and '11' for November. This is a minor formatting concern from an end-user's perspective but a fixed position for the developer.
Craig Oates