Hello, I am writing as a…

Numéro du REO

019-2564

Identifiant (ID) du commentaire

49855

Commentaire fait au nom

Individual

Statut du commentaire

Commentaire

Hello, I am writing as a consumer and open source software (OSS) developer in strong support of ERO 019-2564 but I have some suggestions to make it much more useful for consumers, making it easier to conserve energy.

While the DMD format is fine for one-off or occasional analysis of energy consumption, the tedious process of having to regularly log in and download the data will likely deter consumers from regularly monitoring their usage closely and being able to see the effects of their conservation efforts. CMD has the potential to allow automated access to the usage data but I don't think the proposal is going far enough in requiring that access for consumers without manual hurdles. Ideally once a consumer has setup access to CMD in the software of their choice (including open source software run on their own computer rather than via a third-party), they should never need to log into the utility to continue to update this information in said software. Currently the proposal talks about ideas for the maximum number of clicks to access data but it should be clarified that once CMD is setup there should be no more action required on with the utility company (or its third-party data provider) in order to update data using an existing CMD setup. Solution: I would like to see it enforced in the regulation that CMD can be setup once by a consumer and further updates of the data can be done in a fully automated fashion without any clicks on a website (including no 2FA) since the OAuth token alone is sufficient for authentication. OAuth Refresh tokens should last at least 1 year, ideally indefinitely until the consumer revokes it.

I also have concerns that energy companies will only allow certain third-party software or websites to use CMD rather than any software of the user's choosing who implements the protocol (but isn't necessarily certified). Certification of the software will be an unnecessary burden for open source software developers and simply isn't needed as it's not something required for usage of most APIs online. The regulation should prevent energy companies from limiting which software or website is used for CMD. Without this requirement, I can foresee that only existing marge companies will be allowed to use CMD which will hinder innovation and access to the data. The consumer should be able to choose whatever software they wish. The current proposal talks too much about third-parties when the ideal scenario is that a consumer runs software on their own computer which directly downloads the data via CMD from the utility (without any interaction with the utility after initial setup). This aligns with the proposal's expectation of "fostering the development of innovative and interactive energy management software tools and apps to make the data available to customers in more engaging ways." I have seen success in allowing open source access to utility data via open source software in the Home Assistant home automation software community. There are dozens of existing integrations to allow consumers to monitor their energy usage with utilities around the world but Ontario and Canada are missing from this because of the lack of CMD (or other open API/standard giving consumers access to their usage data).

In summary, the regulation should ensure that open-source software of the consumers choosing should be able to have recurring access via CMD for at least a year without interacting with the utility after initial setup. Utilities should allow access from any software which implements the CMD API without any certification on the software.