The pre_start period should probably be a separate setting in the config.ini to let people set it to what makes sense for them.

I also think adding the reference periods as described by Blobule in the HQ forums (unfortunately there is no direct link to comments available but a search for "11h-14h" should get you to the right one) would be a great addition. I am not sure if it's best to add it as static values or config setting with a default.

I did not know about reference periods last year (I just reduced my consumption during peaks) but I started using it in my automations this year and the difference in credits is major for me (last winter 76$ total credits, this year 35$ with just the first 4 periods!) for the same reduction in usage in peak periods.

So I decided to take the plunge and try to figure out how to accomplish what I want from this project in python. @zepiaf and @clauderobi I am not going to create a PR right away but I you want to take my fork for a run I would be glad to hear your comments. I integrated the new terms, changed some configs to align with hydro's logic, heavily added to the calculations and mqtt topics while trying to maintain what was there as much as possible.

@zepiaf if you like the result I will create a PR.

Initial readme to try and standardise on the various winter credit related terms and their meanings and usages.

The idea is to get a discussion going on a naming scheme that is closely related to the terms used by HQ while still making sense in the context of an home automation system and it's logics.

The TLS handshake is failing at the certificate verification stage. Using openssl s_client -connect session.hydroquebec.com:443 it appears as though the server is not providing the whole certificate chain up to the actual root.

The same verification with openssl s_client -connect www.hydroquebec.com:443 works perfectly. The whole chain is present.

Did you have to manually insert the missing certificates in cacert.pem?

Tried to simplify and refactor the code

Event is now a class Period is now a class

Both are accessed as objects (ie event.date) and can be dumped as dict (event.to_dict())

Major refactoring :

• winter_credit is now a module
• hydro_api only handle hydro quebec API calls and auth
• mqtt now publish the entire objects for both next event and state

Data format is now more versatile:

• pre_start is now pre_heat and has configurable offset
• reference periods are configurable and are calculated for the current day
• all datetime fields have equivalent _ts that correspond to unix epoch (timestamp)

Configuration is now in yaml

Documentation has been updated

There is a fresh credit period coming up tomorrow so I ran to script to see the output and it looks like the last period (2022-01-04) shows under the "future" section and also under "past_winters"

 "current_winter": {
  "past": {
   "1641294000.0": {
    "date": "2022-01-04",
    "start": "06:00:00",
    "end": "09:00:00"
   },
   "1641243600.0": {
    "date": "2022-01-03",
    "start": "16:00:00",
    "end": "20:00:00"
   },
   "1641207600.0": {
    "date": "2022-01-03",
    "start": "06:00:00",
    "end": "09:00:00"
   }
  },
  "future": {
   "1641675600.0": {
    "date": "2022-01-08",
    "start": "16:00:00",
    "end": "20:00:00"
   },
   "1641639600.0": {
    "date": "2022-01-08",
    "start": "06:00:00",
    "end": "09:00:00"
   },
   "1641330000.0": {
    "date": "2022-01-04",
    "start": "16:00:00",
    "end": "20:00:00"
   }
  }
 },
 "past_winters": {},
 "next": {
  "1641330000.0": {
   "date": "2022-01-04",
   "start": "16:00:00",
   "end": "20:00:00"
  }
 }
}

I started to get the following error after this morning's critical peak. There is probably something wrong with the logic when there is no next critical event.

  File "mqtt.py", line 34, in <module>
    next_event = w.getNextEvent().to_dict()
AttributeError: 'dict' object has no attribute 'to_dict'

The pre_heat configs were missing from config.yaml.default and fix pre_heat logic to use config.periods instead of config.events

I also added a logic that if pre_heat_start_offset = 0 we won't be calculating and pushing it.

After some testing with mqtt.py I had some runs that would not populate all the values (start with no end or vice-versa). Adding a qos of 1 seems to have solved it.

I also enabled retain so that if mqtt.py publishes while the client system (home-assistant, node-red, etc) is not connected to MQTT the information can still be fetched later on when the connection is re-established.

I just tried it and it work well and all my info is correctly extracted. I noticed a few typing errors and figured I would correct them.

Thanks for the work on this!

How would you integrate it in HassOS ?

I tried using AppDaemon 4 Add-on without luck, it looks like that only works with official python projects from https://pypi.org/

Maybe I could figure out how they package their projects and fit your project somehow?

Otherwise I could setup another VM with Python 3 on it and use MQTT Integration in HassOS but that would involve managing an extra machine just for that, I wish I could package everything in a single VM.

Thanks for your great work, I can't wait to use it!

Originally posted by @jchretien in https://github.com/zepiaf/hydroqc/issues/16#issuecomment-1012619791

I thought it might be a good thing to know what people are working with when automating for Hydro winter credits to share ideas.

Software I am using home-assistant, node-red and emqx (mqtt) running on a Kubernetes cluster.

Electric Loads My loads are controlled by the following:

• Geothermal system : waterfurnace_aurora
• Heat exchanger : zwave relay switch
• Whole house humidifier : zwave relay with fan interlock with the geothermal system
• Water Heater : insteon heavy duty relay
• EV (leaf 2015) : OVMS, its EVDUTY-30 smart-home (not smart at all) charger will be replaced by a OpenEVSE charger soon which should let me fully automate the charge cycle.
• Everything else is a combination of Insteon and Zwave, Insteon being slowly replaced by Zwave when they die

Logic / automations Currently most of my Hydro related automations are in Node-Red where I have a flow that fetches my email looking for the Hydro notification and then parses everything to set input_datetimes in home-assistant. I plan to change this logic to use the current project once it is a bit more mature. Some of my power management logic is described in this comment

As I see it, there are 3 things in this project:

• a library that does the low level stuff
• a "dumb" high level application that currently simply dump the raw data
• an MQTT publisher (I did not look into this but I am familiar with MQTT; I guess you publish something)

I usually like to have the library in a separate project but I am ok with the way it is know unless the dependencies for the non library stuff is not too long...

Anyway, the suggestion I wan to make is to create a "smarter" high application that abstract away the low level and spit out some high level information on screen (formated and/or JSON) and/or in a JSON file. The abstraction should actually be in the library since I suspect the MQTT stuff will definitely benefits from that as well. The benefit of having this high level application is to make the project useful for other that do not want or do not care about MQTT.

As for high level abstraction, considering that what most people are interested is to know if a peek period is pending or not I suggest this list: 1 - what is the current type of "moment", i.e - nothing special - morning prestart for non peek days - morning peek time for non peek days - afternoon prestart for non peek days - afternoon peek time for non peek days - morning prestart for a peek days - morning peek time for a peek days - afternoon prestart for a peek days - afternoon peek time for a peek days 2 - is the next day going to be a peek day or not (the heating inertia of my home is so large that I usually need to start adjusting the previous evening...)

At this moment I do not see other high level abstracts for home automation reasons, however, I guess the hourly consumption report to JSON file would make sense (in append mode obviously, which means to use line-delimited JSON records format).