Make each OpenEVSE unique and discoverable

[glynhudson]

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:

• Wifi AP SSID, currently uses chip-ID but should be reduced to 4 characters for consistency?
• hostname
• MQTT base-topic
• Emoncms node name

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

• MQTT initial connection message to openevse/announce/<chip ID> topic. The message will be a JSON block of the format:

{
  "state":"connected",
  "name":"openevse-<chipID>",
  "mqtt":"<MQTT base topic>",
  "http":"<HTTP endpoint>"
}

• MQTT LWT (last will testament) disconnection message to openevse/announce/<chip ID> topic
  The message will be a JSON block of the format:

{
  "state":"disconnected",
  "name":"openevse-<chipID>"
}

Both the initial connection message and LWT should have MQTT retain flag set

[chris1howell]

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> .

[glynhudson]

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?

[glynhudson]

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

[glynhudson]

@chris1howell @beaylott what do you think of the MQTT topic suggestions above.

[jeremypoulter]

I quite like how Sonoff Tasmota works, using %xxx% template substitution in various config elements, so we could have the defaults of;

• Hostname: openevse_%chipid%
• MQTT topic: emoncms/%hostname% or openevse/%chipid%
• EmonCMS node: %hostname%

This would make it very configurable rather than just on/off, what do you think?

[beaylott]

@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.

[glynhudson]

This would make it very configurable rather than just on/off, what do you think?

Yes, that sounds excellent but maybe overly complex? A simpler implementation could be just each metric appended with _<chipID> then user could edit these metrics if required. e.g default hostname would be http://openevse_XXXX but could be user edited via advance options (already implemented) if required.

@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).

Does what I suggested above not satisfy this requirement:

MQTT initial connection message eg. connected- to openevse/announce topic

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!

I think an MQTT broker only stores one retained message per topic?

Yes, that's correct.

[jeremypoulter]

if the announce topic was openevse/announce/<chipid> then you could just subscribe to openevse/announce/% and get all the states of the known devices, and that would be persisted.

How should the base topic relate to this changes? Should the announce topic be configurable independently?

[glynhudson]

if the announce topic was openevse/announce/ then you could just subscribe to openevse/announce/% and get all the states of the known devices, and that would be persisted.

That's a good idea. Do you agree @beaylott ? Would this suit your application and integrate with HA?

How should the base topic relate to this changes? Should the announce topic be configurable independently?

I think it's fine for the announce topic to be fixed as openeve/announce but I guess there is not harm for it to be user configurable if required. I think ad well as publishing the chipID we should also publish the word connected / disconnected. See below:

---

To summarize

The default strings for the following should be openevse-<chipID> where chipID is the last four characters of the ESP chipD e.g openevse-1234

• Wi-Fi AP SSID, currently uses chip-ID but should be reduced to 4 characters for consistency
• hostname
• MQTT base-topic e.g
• Emoncms node name e.g

On MQTT connection the word connected-<chipID> should be published to openevse/announce with the persistence flag enabled.

The MQTT last will testament (LWT) should be set to publish disconnected-<chipID> to openevse/announce when the openevse disconnects from MQTT

[glynhudson]

Just spoken to @beaylott, these changes suggested will work fine for the OpenDSR project.

[jeremypoulter]

@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.

[jeremypoulter]

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:

ESP32 Gateway
HAL.getLongId(10) = 39628657771768    1768
HAL.getLongId(16) = 240ac411c4f8      c4f8
HAL.getLongId(64) = JArEEcT4          EcT4

ESP32 Wrover
HAL.getLongId(10) = 39628657764308    4308
HAL.getLongId(16) = 240ac411a7d4      a7d4
HAL.getLongId(64) = JArEEafU          EafU

NodeMCU-32s
HAL.getLongId(10) = 39628657801068    1068
HAL.getLongId(16) = 240ac412376c      376c
HAL.getLongId(64) = JArEEjds          Ejds

Feather Huzzah32
HAL.getLongId(10) = 53526635556496    6496
HAL.getLongId(16) = 30aea4192e90      2e90
HAL.getLongId(64) = MK6kGS6Q          GS6Q

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?

[glynhudson]

Nice work.

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.

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.

[jeremypoulter]

and will always be unique

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)

[glynhudson]

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

[jeremypoulter]

@glynhudson made the changes, please review and let me know what you think

[glynhudson]

@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 openevse/announce/55ac

{
  "state": "connected",
  "id": "c94f330d55ac",
  "name": "openevse-55ac",
  "mqtt": "emonevse",
  "http": "http://192.168.86.20/"
}

The base topic enonevse was manually set.

Example when the unit is disconnected. The following is posted to openevse/announce/55ac

{
  "state": "disconnected",
  "id": "c44f330d55ad",
  "name": "openevse-55ad"
}

Hostname http://openevse-55ad.local/ is also working, however I'm still experiencing #19 #24