Add more hardware information to simplify OTA

[nicola-lunghi]

I have the situation in a network where I have two kind of cpu (ESP-32 and ESP-8266) and some of the ESP-8266 boards have different EEPROM sizes (4M and 2M)

Also if the cpu are the same the physical board have different fuinctionality

I have:

• an ESP8266 that is reporting temperature values from a temperature sensor
• another ESP8266 that is reporting light values
• another ESP8266 that is switching a relay

So If I want to implement a firmware update I need a different firmware for each board

I need

• cpu name es. "esp32"
• eeprom-size → "2048"
• board name → "SQW-LIGHT"
• board revision → "A0.1"

Where I could put those information?

[fermuch]

I'm doing it like this:

$fw/name → my-firmware-for-esp32
$fw/version → 0.2.3
$implementation → fermuch-esp32
$implementation/board → foobar2000
$implementation/board-rev → 1.3-dev

I think the only thing we don't have in common is the eeprom-size, but you can add it as an $implementation.

[ThomDietrich]

From #76:

What is the importance of those details to the convention/standardization in terms of automatic discovery and usage? Remember that you can publish anything you like from your device. The Homie convention allows a wide range of data- and actionpoints. Details fixed in the convention are needed to understand and interact with a device automatically. Hardware details are irrelevant in this scenario, if your application on top of the convention needs them, feel free to define them below $implementation.

[davidgraeff]

I noticed, that a lot of the homie mqtt topics are marked as required. Very rarely an "optional" topic is specified and there is absolutely nothing like a "recommended" topic name.

If you look at the OMA LwM2M convention on top of CoAP: They introduced a registry for all kind of objects (which maps to MQTT topics), from Switches, dimmable Lights, to Gyrometers.

I would suggest to just recommend some topics like

$system/arch
$system/memory
$system/totalspace

and give example values as well.

That way a third party OTA updater for instance can easily say: We support OTA updates for Homie 3.x devices that follow the $system recommendations.

[nicola-lunghi]

the thing is that not specifying a "recommended" way of doing this has this risk: everyone implement the same stuff using topic with different names so the solutions even if they could be compatible are not.

Example: I would have called the topic instead of $system for example $hw another guy could use $espdata and we are back in the jungle of incompatible devices.

Instead if one standard suggest names (and make it optional see #86) my implementation and @davidgraeff would be the same so if I get his firmware or his board I can get hardware information in a common way.

[nicola-lunghi]

as commented by @davidgraeff I suggest to insert a lot more topic and make them optional to suggest a possible implementation of a common problem.

also another consideration:
I don;t get the meaning of the $implementation topic should it be $hardware or something similar?

[ThomDietrich]

You can use any subtopics of $implementation for anything related to your specific Homie implementation.

hardware and software. Basically everything you deem relevant

[davidgraeff]

But that's like a wildcard topic: do whatever you want. Why not leave it out of the specification then. Either it is typed and machine readable for something like ota or it should be a user defined normal topic, I guess.

[ThomDietrich]

I have no stron opinion on the $implementation tree at the moment. However you guys were suggesting to define some optional topics here and I can see why this might be useful.

One more thing to look out for: A Homie node implementation framework (like homie-esp8266) might limit a user in the possibilities to "user define normal topics"...

Besides all of that you know that my opinion is to limit the convention to what is necessary for automatic discovery.

[davidgraeff]

Just think about openhab/esh. I guess other home automation systems (controllers in homie speak) do it similar. In ESH a thing does have a location. And it does support firmware updates. So you could argue that for IOT devices, OTA update availability and locations are part of the discovery process.

[davidgraeff]

I have to talk to Marvin about homie-esp8266. I think it should be more modular. One library for homie, one for homie-ota, one for bootstrapping a WiFi device. At the moment it is all in one. A homie library should not prevent a user from publishing and subscribing to custom mqtt topics.

[euphi]

Yes, there already was the proposal to implement homie-esp8266 in a more modular way (e.g. there).

Oh, and Homie-esp8266 can give you a reference to the AsyncMQTTClient instance, so any user can subscribe to other topics.

Regarding location:

• location is very useful for auto-discovery, so I like the idea of adding it to the convention as optional device property.

[timpur]

@davidgraeff, again, i dont think ESH should define Homie. Yes its great to get ideas from other place, but i dont think just because ESH has it home needs it. Homie is about core discovery through mqtt, if you want a to have something that is for ESH i recommend you fork this add on to this call it Homie for ESH. You can do the same for the esp8266 implementation.

as @ThomDietrich said:

Besides all of that you know that my opinion is to limit the convention to what is necessary for automatic discovery.

I worried about Homie getting bloated.....

I think that the OTA idea being part of the convention is crazy. OTA has nothing to do with discovery of devices, and keep in mind some implementations are not IOT devices, this is the great thing about homie, you could create server monitor device for your RPI that is automatically discoverable in your choice of Home automation controller or your own applications.

Hopefully soon we will have discover libs in many languages that allow devs to implement homie into any platform (EHS , Home Assistant ...) or their own services. This my hope for homie, and i keep this in perspective when participating in the homie convention, homie is for many platforms and implementations and should not show any bias to certain platforms.

[davidgraeff]

Timpur. Please do me the favour and read my full posts. I'm using ESH because I know it the best. It is just an example platform among other platforms. You seem to react allergic to every post where I mention ESH, so I leave that out from now on. That's fine.

Back to the topic. Of course, capability discovery can be part of homie, as you pointed out it is about discovery. OTA updates should not be part of this spec, nobody actually requested it. You need a software version, free space info, some hardware info like the architecture and one or two more device states for OTA availability discovery.

You might be confused because I mentioned modularity of esp8266-homie and the homie-ota part. That has nothing to do with the spec, it is about that specific implementation that supports OTA but mixed all that functionality into one lib. I would appreciate if the OTA part could be separated from the rest. We are on the same side :)

[timpur]

@davidgraeff I can see that can out as really harsh, and sorry for that, just want to make sure that we keep things into perspective what homie is and isn't.

The reason I worry is because in other post you have mentioned that you found boardcast messages 'useless' because you don't know what to do with them in ESH, doesn't mean they don't have a reason and place.

In my opinion broadcasts are still... Useless. The one big reason is: ... Should I display them to the user, like notifications? But then the source is missing. I really have no idea what to do with them.

[ThomDietrich]

@davidgraeff I think it is very important that you continue thinking and discussing from the ESH angle. You are one of the first to develop the controller side of Homie and it is imho important to benefit from your experience there. Other than most you are probably the one focused the most on discoverability and after all, this is the most important goal of Homie.

I can agree with @timpur that you should be careful to judge only based on ESH principles. On the other hand I feel like orienting design decisions based on experience-based decisions in ESH will not hurt.

[timpur]

@ThomDietrich totally behind that :)

Though i also have implemented a discovery implementation for Home Assistant (still a work in progress V2.0.1) :(

[ThomDietrich]

I know, I know. "One of the first" was not supposed to exclude you :)

[nicola-lunghi]

one question:
what happened to the $fw/checksum property?

here
http://marvinroger.github.io/homie-esp8266/docs/develop/others/ota-configuration-updates/

it says

During startup of the Homie for ESP8266 device, it reports the current firmware's MD5 to $fw/checksum (in addition to $fw/name and $fw/version).

[davidgraeff]

Hopefully $fw disappears completely from the convention to be honest. It's not enough information to do anything useful with it.

[timpur]

I think $fw has its use. Allows for tracking of firmware name and version.

Though this is way more useful with OTA, some platforms might not have OTA and this is a greater way of tracking manually...

http://marvinroger.github.io/homie-esp8266/docs/develop/others/ota-configuration-updates/

Currently we also add a checksum to $fw which isn't allowed in the current version, wondering if we should allow extension ?

[davidgraeff]

That's what I mean. It is useless in its current form without adding additional information. Why should someone be interested in the version, if the device doesn't support updates?

As I understood, the convention is for discovery of available topics and their semantics. Everything else can be specified on top of it. Can't it?

[davidgraeff]

Close in favour of #130