Thermostat Schedule Retrieval Code #38
Conversation
…n and cleaned up structs
…ame in schedule retrieval AJAX request
|
@gtfierro I had a question with regards to representing time. I took your recommendation from above and used RRule to standardize the time format for the Pelican, but I feel like the way I did it wasn't particularly elegant. From reading the RRule documentation, it seems like every New RRule entry requires a "DTStart" field (which is really just a time.time golang object). DTStart specifies the first occurrence of the scheduled event, kind of like the start date of recurring events in Google Calendar. My approach was to use RRule to standardize the time, but it seems like RRule events require a start date. However, when it comes to the Pelican, I'm not sure what I should set the start date to. The Pelican schedule only gives me hour, minute, and AM/PM of each event block, and there's no history of when the schedule might've been last edited. As a result, as you can see in the convertTimeToRRule function, when creating the DTStart, I arbitrarily set the month, date, and year to 0, 0, 0. I think the main issue is that when it comes to time, Pelican only provides something like "6:00:AM", but it seems like creating an RRule event requires a lot more parameters, most notably, a start date. Should we either 1. put in dummy values for those parameters 2. use a different time format or 3. something else? Also for context, Pelican scheduling occurs, at most, on a weekly basis. There are 3 different settings
|
|
@john-b-yang Its probably fine to start the recurrence rule at the "0" date for now, but it is important that we capture the weekly pattern of the schedule and not just the hour. The pelican schedule scraper i wrote was able to take care of this. but I remember having to get the javascript to render the schedule viewer in order to extract that information |
…Added wkst field to RRule time to track day of week.
|
@gtfierro No problem, sounds good. The way I have the results set up is as follows The ThermostatSchedule struct contains a map between a string and a ThermostatDaySchedule struct. In this case, the "string" key will be the day itself ("Sunday", "Monday"..."Saturday"). Then, each ThermostatDaySchedule itself is a series of "Blocks". I created a struct that would account how a Pelican's daily schedule consists of several different "blocks" of settings. Each Block consists of 4 fields: heatSetting, coolSetting, System (Setting aka auto, heat, cool, off), and Time. The Time RRule, after your suggestions above, now reflects 1. the time 2. timezone and 3. the day of week. Hopefully this answers your question? I was able to get all of this data by inspecting the AJAX requests that were called when the schedule settings pages were being rendered. |
|
Have you tested this among multiple types of schedule definition? Pelican supports at least 3, I think. Not sure where those are documented, but if you look at the requests the frontend makes, then there is some variation in them. The overview of the schedule struct sounds good; can you document what some of the fields mean? |
|
Yup! The Pelican has three different schedule types,
Thanks! I've added some comments above each struct within the thermSchedule.go file describing the utility of each of the structs. I'm also writing the schedule setting code now so I'll be using this same set of structs as setpoint message for altering the schedule. |
|
@jhkolb @gtfierro I added the markdown file describing the expectations for the schedule structs interface mentioned in SoftwareDefinedBuildings/XBOS#80. The file is called "interface.md" and I discuss a bit about how the schedule is defined given the Pelican thermostat's settings. |
|
Thanks! I added a few comments to clarify the schedule interface; let me know when you get a chance to address those |
|
@gtfierro Thanks for the feedback! Made some updates accordingly :) |
…Rule gets converted to string.
|
@jhkolb do you still have outstanding requests? Your previous review is outdated with the current commit so its hard to track things down. I'm good to merge this when you are |
…oncise with time.Parse function
…pelling, replaced scheduler go requests with pelican field.
|
Okay, I had a couple of additional questions. Once those are answered and you've made the changes to the |
…figured cookie and id setting logic to be set/refreshed once every month. Modified multiple method headers, eliminating the number of parameters and deferring to the pelican struct fields instead.
…eld within Pelican struct
| if err != nil { | ||
| fmt.Printf("Failed to create Schedule msgpack PO: %v", err) | ||
| } | ||
| currentSchedIface.PublishSignal("info", po) |
There was a problem hiding this comment.
@gtfierro In the Pelican's status retrieval loop, we write to the done channel if an error occurs, which prompts the driver to exit. We chose not to do this in the DR event retrieval loop because we figured a problem with the DR interface should be logged but not prompt an exit.
Do you have a preference on which approach we take here? As it stands, an error during schedule retrieval will be logged but the driver will keep running.
There was a problem hiding this comment.
I like the "log but keep going" approach, like we did with DR event retrieval
There was a problem hiding this comment.
Sounds good. I think this is ready then!
Created a new file thermSchedule.go within the types directory of the pelican driver code.
The Pelican Thermostat API does not have a way to retrieve thermostat schedule data. ThermSchedule.go sends AJAX Requests to the climate control website to scrape the desired data from the website itself. The thermSchedule.go exposes one method, getSchedule, that performs this task. Within main.go and params.yml, polling code and an interval parameter has been added. This code is very similar to the existing status and demand response polling code.