Launch HN: Pelm (YC W22) – Plaid for Utilities(pelm.com)
pelm.com
Launch HN: Pelm (YC W22) – Plaid for Utilities
https://www.pelm.com/use-cases
90 comments
Hi Drew and Edmund,
I'm a FE developer on Arc (Arcadia’s API Platform), and I was surprised to see how similar Pelm was to some of the projects I've worked on, considering the release of Arc "took you by surprise."
Your designs on your website look very close to the design of our connect widget and even has the same copy.
For example, this is the Arcadia landing page: https://i.imgur.com/FkPq6S5.png While this is the landing page on your website: https://i.imgur.com/dVVOSqD.png
It gets worse on the "success" screen: https://i.imgur.com/kzgyTwv.png
I'd like to view this as a coincidence, but I viewed your Pelm-Connect repo and thought the documentation looked familiar: https://i.imgur.com/hYWIk6d.png
I looked at the commit history in the git repo, and found it was copied from our documentation: https://i.imgur.com/DF8aqFl.png https://github.com/Pelm-Technologies/react-pelm-connect/comm... https://github.com/Pelm-Technologies/react-pelm-connect/comm...
Our whole team has worked hard on our API for months, so it's really disheartening to see it copied like this.
If anyone is interested in Arc, which supports 125 utilities and has had people working on the utility data problem for 5 years, you can sign up at https://arc.arcadia.com/signup.
I'm a FE developer on Arc (Arcadia’s API Platform), and I was surprised to see how similar Pelm was to some of the projects I've worked on, considering the release of Arc "took you by surprise."
Your designs on your website look very close to the design of our connect widget and even has the same copy.
For example, this is the Arcadia landing page: https://i.imgur.com/FkPq6S5.png While this is the landing page on your website: https://i.imgur.com/dVVOSqD.png
It gets worse on the "success" screen: https://i.imgur.com/kzgyTwv.png
I'd like to view this as a coincidence, but I viewed your Pelm-Connect repo and thought the documentation looked familiar: https://i.imgur.com/hYWIk6d.png
I looked at the commit history in the git repo, and found it was copied from our documentation: https://i.imgur.com/DF8aqFl.png https://github.com/Pelm-Technologies/react-pelm-connect/comm... https://github.com/Pelm-Technologies/react-pelm-connect/comm...
Our whole team has worked hard on our API for months, so it's really disheartening to see it copied like this.
If anyone is interested in Arc, which supports 125 utilities and has had people working on the utility data problem for 5 years, you can sign up at https://arc.arcadia.com/signup.
Hi, Edmund here. I wanted to address some of your concerns since I built Pelm Connect.
Regarding the similarity in design, I believe this is a result of both of our products finding inspiration in Plaid. Plaid has played an insurmountable role in the fintech boom, and I’m sure most could understand why companies like Pelm and Arcadia would look up to them for inspiration.
Regarding the similar copy in our documentation, this was something Pelm could have handled better. Our intention was to find a template as a starting point to work off of, and in hindsight, we should have just started from scratch. We’ve completely rewritten our Pelm Connect documentation.
Please understand that we had no malicious intentions and did not mean to discredit the hard work of Arcadia. We believe that Pelm and Arcadia have the same goal of democratizing access to energy data in service of making the world more sustainable. We’re excited that competition in the space will spur innovation and help us move closer to solving a dire problem.
Regarding the similarity in design, I believe this is a result of both of our products finding inspiration in Plaid. Plaid has played an insurmountable role in the fintech boom, and I’m sure most could understand why companies like Pelm and Arcadia would look up to them for inspiration.
Regarding the similar copy in our documentation, this was something Pelm could have handled better. Our intention was to find a template as a starting point to work off of, and in hindsight, we should have just started from scratch. We’ve completely rewritten our Pelm Connect documentation.
Please understand that we had no malicious intentions and did not mean to discredit the hard work of Arcadia. We believe that Pelm and Arcadia have the same goal of democratizing access to energy data in service of making the world more sustainable. We’re excited that competition in the space will spur innovation and help us move closer to solving a dire problem.
Fantastic copy-paste job, Pelm!
Can’t wait to see when your copy of Arcadia’s work is finished!!!
Can’t wait to see when your copy of Arcadia’s work is finished!!!
Looks like they took down the repo...oof
savage
lol
Hey, friendly founder advice. Your opening hero and sub text does nothing to actually describe what your API is. This text you wrote would in my opinion be way better
"We are building an API that allows developers to access energy data, such as electricity usage or billing data, from utilities."
Change it to "An API to access your users utilities"
sub text: "Our API gives you access to your users energy data, such as electricity usage or billing data, to help build richer more meaningful applications in X industries"
Anyways, congrats on the launch!
"We are building an API that allows developers to access energy data, such as electricity usage or billing data, from utilities."
Change it to "An API to access your users utilities"
sub text: "Our API gives you access to your users energy data, such as electricity usage or billing data, to help build richer more meaningful applications in X industries"
Anyways, congrats on the launch!
[deleted]
Aaaannnnddd just like that your text has already been updated. Love the new hero text :).
Literally one minute later, wow! Love it! Congrats on the launch!
This looks pretty great. My first potential use case is as for a HomeAssistant addon to tie into HA's existing energy monitoring infrastructure. Is there any chance of a free plan for consumers so we don't need to sign up and pay $3.00 a month to retrieve energy usage for home use? I imagine that the mindshare among developer types would be worth the minimal calls, but obviously this is your decision :)
Thanks again for building this!
Thanks again for building this!
Pelm is free up to 100 API calls and 10 active end users per month! I believe this should be enough to cover the home use case.
Oh awesome! Thanks!
i was also wondering about this right off the bat. it's something i'd prominently explain right at the beginning on the home page, because you want trials to be exceedingly obvious and frictionless (and without having to have you two involved!). it's a great way to build your funnel (and get word-of-mouth) at low cost.
I've added that info to the text above.
I work on the JSON API (I dare not call it REST) layer at Exelon. This is neat. Did you know we have some OpenAPI docs now? I saw you mentioned ComEd in another comment :)
That is really cool. Is it available to the public?
If not, I’d love to get a more accurate estimate from solar companies without having to fish around for my average usage.
If not, I’d love to get a more accurate estimate from solar companies without having to fish around for my average usage.
I did not; thanks for the heads up!
Yeah so besides ComEd, I wouldn't think it would be too difficult to integrate with the other five opcos that Exelon owns because they all use the same api layer. This would double your number of energy customers from ~4 million to ~10 million ;) Of course, I have no idea what sort of arrangement you initiated with ComEd!
Ah, nice! Getting all of Exelon for the cost of one would be quite awesome. We'll dig into it.
I used to work at a startup which did the same thing for health records.
In fact, our frontend plugin was also called "Connect".
As an end user, it sounds like you will take my credentials for my utility provider, log into their website with those credentials, extract my data, store it in a normalized form in your DB, and expose it through your REST API.
Is this true?
If so, while you are logged in, you will also have access to financial information (e.g. bank account information, billing info, etc.). This is pretty sensitive data. What kind of guarantees are you making about not touching that data?
(All this assumes that my model for how Pelm works is true. Apologies if it isn't.)
In fact, our frontend plugin was also called "Connect".
As an end user, it sounds like you will take my credentials for my utility provider, log into their website with those credentials, extract my data, store it in a normalized form in your DB, and expose it through your REST API.
Is this true?
If so, while you are logged in, you will also have access to financial information (e.g. bank account information, billing info, etc.). This is pretty sensitive data. What kind of guarantees are you making about not touching that data?
(All this assumes that my model for how Pelm works is true. Apologies if it isn't.)
You nailed it!
First guarantee is that nobody is manually going in and poking around your account details since the process you've described happens entirely programmatically.
Now, we could program our system to do things other than what's mentioned. However, we're quite disinterested in (actually, emphatically against) ruining our trust/reputation with customers (plus the general public) given our dependence on such relationships and desire to succeed as a company. All that's to say, the second guarantee is that we won't be touching such sensitive data unless given permission to do so by the user.
An example of when we might need to is if the user wants to pay their utility bill using stored payment options instead of submitting payment information. Even in this case, there won't be human eyes on this data; only our Python backend will be interacting with it.
First guarantee is that nobody is manually going in and poking around your account details since the process you've described happens entirely programmatically.
Now, we could program our system to do things other than what's mentioned. However, we're quite disinterested in (actually, emphatically against) ruining our trust/reputation with customers (plus the general public) given our dependence on such relationships and desire to succeed as a company. All that's to say, the second guarantee is that we won't be touching such sensitive data unless given permission to do so by the user.
An example of when we might need to is if the user wants to pay their utility bill using stored payment options instead of submitting payment information. Even in this case, there won't be human eyes on this data; only our Python backend will be interacting with it.
Take this as constructive feedback.
I don't doubt your intentions but these guarantees don't hold their weight relative to the sensitivity of the data that you will safeguard. Despite the process happening programmatically, developers will still have access to the backend where this occurs. Who has access to this backend? What's stopping any of your engineers from peeking at the database where the credentials are stored? Is this data encrypted at rest and transit? What sort of information is this process logging to either first-party and third-party services? Will the code be audited? What sort of compliance certifications are you planning to obtain?
Maybe you do have answers to these questions so if you do I suggest that you communicate how credentials are properly safeguarded. The guarantees that you mention in this comment don't inspire confidence as a) they can't be taken at face value b) makes me doubt you are taking the due diligence required to manage this data.
Take a look at these examples of companies supporting their claimed guarantees:
* https://1password.com/soc/
* https://plaid.com/safety/
I don't doubt your intentions but these guarantees don't hold their weight relative to the sensitivity of the data that you will safeguard. Despite the process happening programmatically, developers will still have access to the backend where this occurs. Who has access to this backend? What's stopping any of your engineers from peeking at the database where the credentials are stored? Is this data encrypted at rest and transit? What sort of information is this process logging to either first-party and third-party services? Will the code be audited? What sort of compliance certifications are you planning to obtain?
Maybe you do have answers to these questions so if you do I suggest that you communicate how credentials are properly safeguarded. The guarantees that you mention in this comment don't inspire confidence as a) they can't be taken at face value b) makes me doubt you are taking the due diligence required to manage this data.
Take a look at these examples of companies supporting their claimed guarantees:
* https://1password.com/soc/
* https://plaid.com/safety/
Thanks for the feedback! To answer your questions:
- Myself and my co-founder
- Credentials aren't stored in plaintext and the encryption key isn't universally available; "peeking" at the db is quite difficult
- Data (I'm assuming you mean credentials) is encrypted at rest and in transit
- Only business logic and errors are logged: e.g. when processes are completed and why things are breaking
- Yes, eventually
- Definitely ISO 27701 & SOC 2, perhaps others
Our process for safeguarding credentials is mentioned further down in the thread.
I'm not sure what more guarantees we can give to inspire confidence other than statements taken at face value. We don't have the scale or resources to undergo rigorous third party auditing at the moment. On the other hand, one of the first conversations my co-founder and I had was about hiring a security engineer as soon as we could afford one; we definitely take the matter seriously. Did you have any other ideas of ways we can showcase our commitment to security/privacy other than "trust us"? I do agree it's not the best method but am unsure of alternatives.
Our process for safeguarding credentials is mentioned further down in the thread.
I'm not sure what more guarantees we can give to inspire confidence other than statements taken at face value. We don't have the scale or resources to undergo rigorous third party auditing at the moment. On the other hand, one of the first conversations my co-founder and I had was about hiring a security engineer as soon as we could afford one; we definitely take the matter seriously. Did you have any other ideas of ways we can showcase our commitment to security/privacy other than "trust us"? I do agree it's not the best method but am unsure of alternatives.
This should be written down somewhere! I glanced through the website and I couldn't find any mention of the security/safety measures taken other than the UI screenshot where it says "securely connect your utility account".
If I were interested in purchasing this service I would want to know how much I can trust you with my credentials. Perhaps having a page or section in the docs that explain the security measures would be an improvement. There are other ideas in another comment similar to this one.
If I were interested in purchasing this service I would want to know how much I can trust you with my credentials. Perhaps having a page or section in the docs that explain the security measures would be an improvement. There are other ideas in another comment similar to this one.
You could let the utility companies, which users already "trust" evaluate and then recommend/sign-offs on your engine? Or just have the utility embed your engine and bill them?
While I respect your current intentions, I cannot take you at your word in perpetuity because I understand the pressures that come from:
1. Running such a business as an entrepreneur.
2. Running such a system as an engineer.
As an entrepreneur, are you promising your customers clean data regardless of the source? Are you promising AI magic? Are you promising a maximum failure rate?
From an engineering standpoint, how will you deal with portals changing their frontends and breaking your scrapers at any time?
I cannot know what you will do in response to these pressures, but I do know that the temptation will exist to build a system that puts a human in the loop to manually collect data from portals, to manually evaluate scrapers, to manually sift through the data and figure out what kind of Machine Learning models you can use to make your business function more effectively.
1. Running such a business as an entrepreneur.
2. Running such a system as an engineer.
As an entrepreneur, are you promising your customers clean data regardless of the source? Are you promising AI magic? Are you promising a maximum failure rate?
From an engineering standpoint, how will you deal with portals changing their frontends and breaking your scrapers at any time?
I cannot know what you will do in response to these pressures, but I do know that the temptation will exist to build a system that puts a human in the loop to manually collect data from portals, to manually evaluate scrapers, to manually sift through the data and figure out what kind of Machine Learning models you can use to make your business function more effectively.
Have you considered sending users to the website to update payment information? Or if not, do you perform the PCI auditing process for your handling of payment information through your systems?
I don’t personally need the answers to these pair of questions, but I wanted to put them on your radar if they’re not already. I trust Plaid far enough to scrape account providers for me, but I do not trust Plaid far enough to provide Plaid my payment details — even if Plaid could theoretically construct them, that’s just not the relationship I want with a data conduit provider.
I don’t personally need the answers to these pair of questions, but I wanted to put them on your radar if they’re not already. I trust Plaid far enough to scrape account providers for me, but I do not trust Plaid far enough to provide Plaid my payment details — even if Plaid could theoretically construct them, that’s just not the relationship I want with a data conduit provider.
Do they actually? My provider only lets me edit those details (with a low quality preview of first 4 digits and a CC icon). Interesting that yours makes those visible to you. You literally can't get those out of my provider. The data doesn't make it out.
This is also what we've encountered so far...though it's probably safe to assume at least a few providers have looser security protocols.
Other billing information is always available such as:
- Am I behind on my power bills? By how much?
- How many credit cards do I have on file and how many are expired?
Such information is still sensitive even if it doesn't leak full credit card numbers.
Also, anyone who has ever used City of Palo Alto Utilities should probably fear for their credit card information.
- Am I behind on my power bills? By how much?
- How many credit cards do I have on file and how many are expired?
Such information is still sensitive even if it doesn't leak full credit card numbers.
Also, anyone who has ever used City of Palo Alto Utilities should probably fear for their credit card information.
I think if your threat model involves that being risky, it's probably best not to use Plaid/Pelm/Arcadia. My threat model and that of any users I can imagine is not in that realm.
I don't use Plaid and as a result I also don't use services like Brex which are impossible to use if you reject Plaid.
Seems consistent with your threat model. Good work.
This product seems really cool!
If I can request a utility, could you support National Grid https://www.nationalgridus.com ?
If I can request a utility, could you support National Grid https://www.nationalgridus.com ?
It's definitely on our roadmap...when we get to it largely depends on the needs of our early customers but know that we have it in mind!
Do you have a developer sandbox with some example data? It's not feasible for the developer to create accounts with different providers if some are across the country.
We do! You can call our endpoints with a "sandbox" header to get mock data. I realize this isn't outlined in our docs--we'll fix that ASAP and I'll comment here when it's done.
Here's the guide to using sandbox mode: https://pelm.readme.io/reference/sandbox-mode
Two questions:
How are you connecting to the users energy supplier, I assume most don't have their own apis and so you are having to save the users login credentials? If so you should list the security measures you are taking to ensure that are safely stored. This is much like how developers had to connect to banks before they started supporting standard apis.
Which utility companies can you currently connect to? Again may be worth listing them on the site.
How are you connecting to the users energy supplier, I assume most don't have their own apis and so you are having to save the users login credentials? If so you should list the security measures you are taking to ensure that are safely stored. This is much like how developers had to connect to banks before they started supporting standard apis.
Which utility companies can you currently connect to? Again may be worth listing them on the site.
Great callout. Passwords are encrypted using a 256-bit AES cipher and are never persisted or shown to developers in plaintext. We currently support PG&E and SCE with a ComEd integration landing within the week.
What does it cost a utility to add e.g. read-only OAuth token support to their customer-facing app?
FWIU, it's pretty easy to add OAuth support to any HTTP API endpoint with e.g. Nginx auth_request or by integrating an OAuth library with automated tests into the application at the url routes, if nothing else.
Do you have a "Guide for utilities who want users to have a safe third-party read-only API", a Developer portal, or like a decision tree for which script to read a decision-maker or a front-line lackey who doesn't know anything about APIs?
Does Pelm integrate with Zapier? https://zapier.com/platform
FWIU, it's pretty easy to add OAuth support to any HTTP API endpoint with e.g. Nginx auth_request or by integrating an OAuth library with automated tests into the application at the url routes, if nothing else.
Do you have a "Guide for utilities who want users to have a safe third-party read-only API", a Developer portal, or like a decision tree for which script to read a decision-maker or a front-line lackey who doesn't know anything about APIs?
Does Pelm integrate with Zapier? https://zapier.com/platform
Can you go into more detail about this? I may be misunderstanding, but I read 'never persisted' as meaning my users must provide credentials for every API call.
Ah, I meant plaintext passwords are never persisted in a db anywhere. The only time passwords are decrypted are when they are used to programmatically log in, so they're never stored anywhere except in memory.
Out of interest what’s the architecture you have gone with for key rotation and storage, and where the encrypted passwords are stored. (Understand that as an very early stage startup you probably haven’t optimised all this yet)
I know some other services that have had to go this route have used quite elaborate systems to ensure separation between keys, passwords and user details in the event of a hack.
I know some other services that have had to go this route have used quite elaborate systems to ensure separation between keys, passwords and user details in the event of a hack.
Really cool use-cases! I wonder why you decided to move them under a separate page instead of showcasing them front and center?
Right now the focus seems to be how easy it is for developers to get going, but it doesn’t really talk to me why I should be doing it.
Once I read the use-cases I get the idea and I’m impressed, but the drop off from people not bothering to click on a 2nd page can be surprisingly big.
Right now the focus seems to be how easy it is for developers to get going, but it doesn’t really talk to me why I should be doing it.
Once I read the use-cases I get the idea and I’m impressed, but the drop off from people not bothering to click on a 2nd page can be surprisingly big.
That's a great point. I've changed the linked URL above to https://www.pelm.com/use-cases. Thanks!
Thanks for the feedback! We had optimism that people would poke around the website more, but I guess we shouldn't assume that.
Ha, I spent a few years around 2015 building exactly this for the first 50 or so largest US utilities on what eventually became https://www.arcadia.com/arc. Curious how you plan to compete. Good luck with the insane number of account edge cases that start popping up at scale and extremely finicky utility sites for scraping, it gets old fast.
We're excited for the challenge!
Arc was released after we'd already been working on this for a while so it did take us a bit by surprise. We'll compete by focusing on building an amazing team and a high quality product.
Arc was released after we'd already been working on this for a while so it did take us a bit by surprise. We'll compete by focusing on building an amazing team and a high quality product.
How is this differentiated from UtilityAPI (https://utilityapi.com/) or other similar products?
UtilityAPI and other products are built by energy companies, not tech companies. We've talked to developers who've used these platforms and they consistently mention an extremely poor developer experience; lack of clear documentation, difficulty in building integrations quickly, little to no support, etc. One example: we talked to a paying customer of UtilityAPI who asked for a specific feature, and UtilityAPI asked him to pay for the development costs of it.
We are software engineers by trade and know how to build a really good developer experience. We're focusing on ease-of-use from the start and will build a stellar engineering team that in turn will help us develop a higher quality product.
We are software engineers by trade and know how to build a really good developer experience. We're focusing on ease-of-use from the start and will build a stellar engineering team that in turn will help us develop a higher quality product.
https://utilityapi.com/about
I think UtilityAPI was founded by "tech people" as well. I wonder if you have any specific examples or comparisons that would make me want to use your service over a well-established company?
I work in the energy industry, and while I would love to just try out your service for comparison, I don't have the time. Your site is very lacking in details.
Also, you said you know how to build a "really good developer experience" without "lack of clear documentation", but the most basic endpoint you have for collecting energy usage intervals (https://pelm.readme.io/reference/get_accounts-account-id-int...) does not have a good example for the data you return for a 200 response; I can't tell what the actual data will look like! You state it's tuples with `(timestamp, value)` but do not show an actual example with tuples in your docs. Compare that to UtilityAPI's docs for the same type of endpoint (https://utilityapi.com/docs/api/intervals) which have a very detailed example.
I would say you have some work to do, but good luck! I would love to see multiple good alternatives for collecting energy utility data.
I think UtilityAPI was founded by "tech people" as well. I wonder if you have any specific examples or comparisons that would make me want to use your service over a well-established company?
I work in the energy industry, and while I would love to just try out your service for comparison, I don't have the time. Your site is very lacking in details.
Also, you said you know how to build a "really good developer experience" without "lack of clear documentation", but the most basic endpoint you have for collecting energy usage intervals (https://pelm.readme.io/reference/get_accounts-account-id-int...) does not have a good example for the data you return for a 200 response; I can't tell what the actual data will look like! You state it's tuples with `(timestamp, value)` but do not show an actual example with tuples in your docs. Compare that to UtilityAPI's docs for the same type of endpoint (https://utilityapi.com/docs/api/intervals) which have a very detailed example.
I would say you have some work to do, but good luck! I would love to see multiple good alternatives for collecting energy utility data.
Thanks for the feedback; as an early stage startup with two employees, we'll often miss things here and there, so I appreciate the callout for how we can improve our docs. While we may not be established right now and have some work to do, I'm confident we can build an amazing developer experience given time. UtilityAPI might have very detailed docs, but we think the end to end usability is still lacking. This has been the consistent theme we've heard from developers that we've interviewed.
I'm not sure I agree with UtilityAPI being founded by "tech people", though we may have differing definitions on what that means. It seems like most of the high level execs come from the energy industry and don't have software engineering experience.
Could you give examples of the specific details we could add to the website to make it easier for you to onboard?
I'm not sure I agree with UtilityAPI being founded by "tech people", though we may have differing definitions on what that means. It seems like most of the high level execs come from the energy industry and don't have software engineering experience.
Could you give examples of the specific details we could add to the website to make it easier for you to onboard?
The founders may have energy industry experience - which is what you want, since it's the operating domain and they'll have industry information and contacts that 'outsiders' won't - but they seem to have a pretty strong development team: https://utilityapi.com/team.
The founder is pretty active on hn[1]. And coincidentally, his most recent comment is about why it makes sense to work at an energy company as part of market research.
[1] https://news.ycombinator.com/threads?id=diafygi
[1] https://news.ycombinator.com/threads?id=diafygi
I would have the docs much more specific on the results that you'll get back. I think from the looks of it, you're using some automated doc builder which takes your internal specs for the endpoint (like the OpenAPI spec or whatever) and outputs "examples" and the other doc pages.
Here is what you have now for an example response body, which is very lacking:
For instance:
* What is "unit"? I assumed it's electrical units, but if that is the case, it doesn't make much sense to me, because that's not an account-level detail but rather a request detail (I should be able to add a param to the request to get Watts, Kilowatts, or whatever units I want each time).
* The "address" is also sketchy, because it is just a string field, so how do I parse that? will each "line" of the address be separated by a newline, or something else?
* The spec for "intervals" is a list of lists of strings, which is a weird way to output `(timestamp, value)` tuples; I would want to see that specified a bit better as well. I would expect either tuples of numbers (float, int, whatever) or something like a mapping with the meter numbers, timestamps, units, values, etc. specified like this (timestamps could be UTC seconds or (preferably) ISO strings):
That's all just from one endpoint. If you have 2 employees, I would look into hiring a technical doc writer as your 3rd if you're trying to build an "amazing developer experience" and also talking to more commercial customers who might use your product to run large data pipelines for energy controls and such. To me, the documentation is like a canary in a coal mine, and I wouldn't even attempt to use your product as-is because it would take me time to fool around with it to even see what formats the data is in and there is no differentiator from your product and others that makes me want to do that work.
Here is what you have now for an example response body, which is very lacking:
{
"account": {
"id": "string",
"unit": "string",
"account_number": "string",
"address": "string"
},
"intervals": [
[
"string"
]
]
}
{
"account": {
"id": "1234567-123",
"unit": "W",
"account_number": "987654-1",
"address": "AN_ADDRESS"
},
"intervals": [
[
"(1234567.4, 123.0)"
],
[
"(1234568.4, 123.0)"
],
...
]
}
For instance:
* What is "unit"? I assumed it's electrical units, but if that is the case, it doesn't make much sense to me, because that's not an account-level detail but rather a request detail (I should be able to add a param to the request to get Watts, Kilowatts, or whatever units I want each time).
* The "address" is also sketchy, because it is just a string field, so how do I parse that? will each "line" of the address be separated by a newline, or something else?
* The spec for "intervals" is a list of lists of strings, which is a weird way to output `(timestamp, value)` tuples; I would want to see that specified a bit better as well. I would expect either tuples of numbers (float, int, whatever) or something like a mapping with the meter numbers, timestamps, units, values, etc. specified like this (timestamps could be UTC seconds or (preferably) ISO strings):
"intervals": {
[
"meter_id": "meter_123456",
"units": "W",
"timestamps": [
"2022-01-01T12:45:15.123456+00:00",
...
],
"values": [
1500.0,
...
]
]
{
"intervals": {
[
"meter_id": "meter_123456",
"units": "W",
"timestamped_values": [
["2022-01-01T12:45:15.123456+00:00", 1500.0],
...
]
]
{
That's all just from one endpoint. If you have 2 employees, I would look into hiring a technical doc writer as your 3rd if you're trying to build an "amazing developer experience" and also talking to more commercial customers who might use your product to run large data pipelines for energy controls and such. To me, the documentation is like a canary in a coal mine, and I wouldn't even attempt to use your product as-is because it would take me time to fool around with it to even see what formats the data is in and there is no differentiator from your product and others that makes me want to do that work.
Thanks for the great advice! We've created more detailed responses, so hopefully there's now a clearer picture of the output for each endpoint. We've added the more implementation-heavy recommendations (like changing the request body for interval data and splitting the address schema into multiple fields) to our roadmap to be implemented shortly. Really appreciate the scrutiny; way better to work everything out now than having developers run into usability issues. Please let us know if there's anything else you notice!
The pricing feels really steep. For a consumer app where the API is called twice a day, it is almost 7 dollars per month alone. This is just for one user. At this price point it means this is inaccessible for anything other than enterprise apps.
That makes sense; we'll need to think more about pricing consumer differently than enterprise because we've heard that our pricing is actually quite low for enterprise. Appreciate the perspective!
We NEED to stop training users to give away passwords for account X to services that are not X. We NEED to! This is what enables phishing to work! It normalizes this! Please do not do this! Next time some old lady loses her life savings due to phishing, you'll know that in some small part plaid and this helped. They trained her that it is ok to provide her password to someone.
This is my reaction every time I see a service like this. In addition to training users that is somehow okay to just give up your credentials to a 3rd party, you are now indefinitely allowing the storage of passwords in a fully reversible format on a platform you have no control over.
Despite all the best efforts by any company engaging in this practice to protect your passwords, these entities are setting themselves up to have a huge target on their back. The technology they employ relies on being able to decrypt passwords programmatically which means it becomes visible on the server’s RAM and could potentially be triggered to decrypt the password as part of an attack. Given that a majority of people use the same passwords for multiple services, it is likely an attacker would be able to determine credentials for someone’s bank or email account via a credential stuffing attack.
Plaid with a bank that does not support oauth scares the hell out of me and I have backed out of using services because this was the only way to enter bank details. I am still shocked that this is largely considered an okay practice.
Despite all the best efforts by any company engaging in this practice to protect your passwords, these entities are setting themselves up to have a huge target on their back. The technology they employ relies on being able to decrypt passwords programmatically which means it becomes visible on the server’s RAM and could potentially be triggered to decrypt the password as part of an attack. Given that a majority of people use the same passwords for multiple services, it is likely an attacker would be able to determine credentials for someone’s bank or email account via a credential stuffing attack.
Plaid with a bank that does not support oauth scares the hell out of me and I have backed out of using services because this was the only way to enter bank details. I am still shocked that this is largely considered an okay practice.
If utilities gave them any other way, I'm sure they'd be using it.
The three major California utilities have an oAuth 2.0 option (PG&E's is called Share My Data). I wonder if Pelm has considered supporting that.
That is a poor excuse for a clearly bad security practice. That is akin to a mugger saying “if the world gave me another way to make money, I wouldn’t be mugging people”. Some things just shouldn’t be done! This is a hill I’m willing to die (by a thousand downvotes) on!
Requesting ConEd access! I bet you could partner with solar companies to compare what their own software rates vs. what's actually metered back to the grid. I can see Sunny Portal to monitor my solar panels, and I can log into ConEd to see my grid usage... but I cannot combine the two. This might let me do that.
That's a great idea! We've identified a use case with solar companies for aiding in sales...this is a great additional case.
Was just looking for a solution like this to integrate with HomeAssistant. Looking forward to trying this out!
Some feedback: As a potential user of your product, I can't find a list of any utility companies you integrate with?
Also it looks like you're are using Jekyll for your website ("Get to know Midnight Theme")? May want to finish customizing it, some of the menu links don't go anywhere.
Also it looks like you're are using Jekyll for your website ("Get to know Midnight Theme")? May want to finish customizing it, some of the menu links don't go anywhere.
Thanks for the feedback—we'll have a list of utilities we support up shortly.
Which links in particular are broken/where did you see that tagline? I thought we combed through pretty thoroughly but maybe not.
Which links in particular are broken/where did you see that tagline? I thought we combed through pretty thoroughly but maybe not.
note that without js turned on, your "burger" menu doesn't even show up, so links to other pages aren't accessible. you seem to be targeting developers, so there's a good chance a number of them browse with privacy extensions. i'd also suspect that the most interesting traffic for you will come from desktop, so why have a burger menu at all? that's an affordance primarily to accommodate mobile users. just list your primary links at the top and let them wrap on mobile. no js needed!
edit: forgot to note that "Get to know Midnight Theme" shows up in the burger menu, under 'Product'. you don't need either that 'Homepage' link, or even the 'Home' link 1 level up. linking home from the logo is sufficient.
edit: forgot to note that "Get to know Midnight Theme" shows up in the burger menu, under 'Product'. you don't need either that 'Homepage' link, or even the 'Home' link 1 level up. linking home from the logo is sufficient.
Ah, it's the burger menu with broken links! It shouldn't show up unless the browser window is a certain width, but we'll look into scrapping it completely.
cool, i'd suggest the only links you need at the top are 'How it Works', 'Pricing', 'Blog' (for marketing), and 'Contact' (for sales). (edit:) oh yes, and also your call to action, 'Get API Keys'. everything else is footer material, and you already have a fat footer with most of those links anyway.
(i should note that i usually browse in narrow windows, so i often get the mobile version; most designers don't think about how people actually use browsers)
(i should note that i usually browse in narrow windows, so i often get the mobile version; most designers don't think about how people actually use browsers)
Gotcha. Makes sense to keep things simple.
You're not the first person to suggest a blog for marketing purposes...seems like something we should invest in!
You're not the first person to suggest a blog for marketing purposes...seems like something we should invest in!
Hey I saw that you guys took down the repo and put it back up without references to Arcadia’s work!
Don’t worry though, I saved a copy of the HTML and cloned the repo for posterity :)
Don’t worry though, I saved a copy of the HTML and cloned the repo for posterity :)
The unique selling point of such this kind of API service would be that the application/producing consuming this API doesn't need to indirectly ask for their consumer's credentials.
Currently, if you want to build an application on top of energy data, you have to build integrations with utilities across the country. Not only is this time-consuming, it's super frustrating given the lack of data standardization and the clunky, high-friction integration processes that energy companies use. With Pelm, you only have to integrate with one service to access utility data, and you get to use a seamless, well-documented API built by other developers.
We are software engineers (from Asana and Affirm) who are enthusiastic about sustainability and the creation of a more modern energy grid. We talked with lots of developers who were frustrated from trying to work with energy data and saw an opportunity to meet their needs while supporting the push for a more efficient energy grid.
Most companies trying to tackle this problem are energy companies, not technology companies. The products they build don't keep the user in mind and only focus on meeting bare functional requirements. Pelm, by contrast, is by-developers-for-developers. Our focus is ease of use. Our API is simple to get up and running (under ten minutes) and provides clear documentation and instructions.
It works like this: you register for our service and embed Connect (our front-end plugin) into your application. The end user uses Connect to authorize access to their data from their particular utility. We scrape electricity usage and billing data from their utility account and store it in a standardized format in a database. Your application can then query electricity interval data and billing data for the end user through our REST API. We also recently built out functionality to pay utility bills through our API.
Our API is designed for apps that do things like help consumers reduce electricity usage, charge EVs at optimal times, optimize HVAC installs, or educate on climate-friendly practices.
One example of how Pelm can currently be used is in demand response programs—that’s when utilities pay companies to get large amounts of people to reduce their electricity consumption during peak hours. Our API can help measure the reduction, which determines how much the company gets paid. Another example: solar panel installers can use us to show potential clients how much they could save on their electricity bill by installing solar. Another is community solar programs that allow people to buy into remote solar farms and get credit for the generated energy from utilities. Pelm can be used by community solar providers to calculate and bundle bills.
(By the way, an interesting little-known fact: this space is possible because of a 2012 initiative by Obama that required utilities to allow consumers more visibility into their energy consumption habits.)
Pelm is free up to 100 API calls and 10 active end users per month. After that we charge on a usage based plan: $0.10/call and $0.50/active end user up to 10,000 API calls and 1,000 active users. Past that limit, you'll move onto an enterprise plan with a flat monthly rate based on your service level and an adjusted rate for calls and active end users (we’re still figuring out the exact parameters).
We’d love to hear any of your ideas or experiences within this space! We’re always looking for creative approaches to the problem and ways we can better the developer experience we’re building. If you get a chance to test out the API, please share your feedback on how we could improve it. Thanks so much!