-
Notifications
You must be signed in to change notification settings - Fork 112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make each OpenEVSE unique and discoverable #15
Comments
Great idea, perhaps this should be the default.
…On Tue, Aug 27, 2019, 7:05 AM Glyn Hudson ***@***.***> wrote:
When enabled 'unique mode' should append the ESP Chip ID to set the
default hostname, MQTT base-topic and Emoncms node name.
This would be a useful feature to handle multiple EVSE installed in a
single location.
I'm open to name suggestions for this feature, I'm not sure 'unique mode'
best describes this feature.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#15>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAN5QH76RCQP6WK4LABYDITQGUYDVANCNFSM4IQE5FSQ>
.
|
I was considering this but it would make the hostname quite awkward to remember e.g http://openevseXXXX. It would also make setup a bit more awkward since a user could not simply browse to http://openevse to access the web interface I guess the unique hostname could be displayed on the LCD so maybe this is not a big issue. I just assumed since most EVSE's will probably be used on their own this would not be required for most users. Happy to make it default. What do you think? |
Ok, after giving this some more thought, I think your right @chris1howell this should be enabled as standard. I will reword this issue to make it a default state rather than a feature |
@chris1howell @beaylott what do you think of the MQTT topic suggestions above. |
I quite like how Sonoff Tasmota works, using
This would make it very configurable rather than just on/off, what do you think? |
@glynhudson it would also be good to trigger the announce / LWT messages in some way, perhaps by pub a message to the announce topic? Otherwise devices that connect afterwards wont neccesarilly the message (although might see the retained message obviously). I think an MQTT broker only stores one retained message per topic? That isnt a problem for us but it wont work well with multiple devices in this case. |
Yes, that sounds excellent but maybe overly complex? A simpler implementation could be just each metric appended with
Does what I suggested above not satisfy this requirement:
Is your point that if multiple OpenEVSE units all published their announce messages to the same topic then only the last announce message would be retained? The issue is if we make the topic unique then subscribers have no easy way of knowing what the topic will be!
Yes, that's correct. |
if the announce topic was How should the base topic relate to this changes? Should the announce topic be configurable independently? |
That's a good idea. Do you agree @beaylott ? Would this suit your application and integrate with HA?
I think it's fine for the announce topic to be fixed as To summarizeThe default strings for the following should be
On MQTT connection the word The MQTT last will testament (LWT) should be set to publish |
Just spoken to @beaylott, these changes suggested will work fine for the OpenDSR project. |
@beaylott / @glynhudson I have just updated the description with my reading of what needs doing. Obviously the MQTT server needs setting up in order for this all to work. |
Just been playing around with the generating the 4 chars of the name. On the ESP32 the 'Chip ID' is the MAC address so I have written a function in encode in different bases. On the various boarde I have I get the following:
Although on the surface of it Base 64 looked like a good fit as it would make the 4 chars have a higher chance of being unique, however it is not so pleasant to the eye. So I would suggest using base 10 for the hostname, SSID, node ID and other human readable places where it is not the end of the world if there is a clash, but use the 12 char hex value for for M2M cases where you need a higher degree of certainty that the ID is unique. @glynhudson / @beaylott what do you think? |
Nice work.
How about using Base 16 everywhere? A combination of 4 character lower case letter and numbers is not too difficult on the eye and will always be unique. I think there is value on using the same identifier across the whole system to avoid confusion. |
It will only be guaranteed to be unique if you use the full 6 bytes of the chip ID/MAC any cutting this down removes the guarantee and just some degree of probability that it will be unique, so for base 16 that is 1/65,536 (best case, the fact that is is a MAC address may reduce this) |
Sounds good enough for our needs. There is unlikely to be more than a few units installed in a single location |
@glynhudson made the changes, please review and let me know what you think |
MQTT to be working great, nice work 👍 This is an example of what's posted when openevse connects: The following is posted to
The base topic Example when the unit is disconnected. The following is posted to
Hostname http://openevse-55ad.local/ is also working, however I'm still experiencing #19 #24 |
We should make each OpenEVSE unique, this will fix the issues of conflicting devices on a single network and help with integration with services that require unique ID e.g home assistant auto config etc. Each device should have a name consisting of
openevse-
followed by 4 chars representing the 'chip ID`openevse-<chipID>
openevse-1234
The
<chipID>
should be the base64 encoded version of the NIC specific part of the MAC address/Chip ID. Each char in Base64 encodes 6 bits, 6x4=24 which just happens to be the number of chars that should be easy to remember and the number of bits of the MAC NIC.Note: Even though Base64 is case sensitive and some of the context that it will be used (eg host name) are not, it still should be sufficiently unique. Also need to consider the mapping of the '62' and '63'.
We should append ESP Chip ID to the following default strings:
In order for other services to discover the openevse and determine the unique ID the MQTT initial connection message and LWT (last will testament) should be published to a fixed topic e.g
openevse/announce/<chip ID>
topic. The message will be a JSON block of the format:openevse/announce/<chip ID>
topicThe message will be a JSON block of the format:
Both the initial connection message and LWT should have MQTT retain flag set
The text was updated successfully, but these errors were encountered: