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 tablet I'm using most of the time to monitor the system (with Eyes and Ears) is under powered (too many Windows 10 updates at this point by I digress). So, it doesn't handle the increase in RAM needed for this feature very well. I change the LogToggle to provide a way to clear the log area alongside stopping the program logging (reducing RAM usage and processing cycles).
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 a very rough bit of code. This is for testing the possibilty/usability of having the program provide updates using the SpeechSynthesizer class. The initial intention is to have the program denote any change in power status ('gallery1' is now off', 'weld detected by factory1' Etc.) and, if it's any good, expand it from there.
The code changes made here are incomplete but I'm packing up for the day and going home -- it's late. I'm logging the current changes for future reference.
The code added here is more about populating the area created for logging each web request. The XAML code was done in the previous commit. As I stated there, these logs are more about the providing the user of this program visual feedback about the state of the program. There are times when the various devices (light meters/relays) don't update and it's hard to tell if that's Eyes and Ears, the internet connection or the devices on the other end.
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.
The logic for 'factory3' and 'gallery3' is still in place but is not bound to the view (MainPage.xml). The view xml is commented out and not removed. This should make it easier to re-add it if the need comes about.
'factory2' was not updating its timestamp when it received a new reading. It was binding to the wrong property in MainPage.xml (view model). This changes the property to the correct one.