Improvement for Homie 3.1 - nick

[nicola-lunghi]

Some ideas

Log channel

define a log channel for getting debugging information from the dvice

homie/[device-id]/logs/
homie/[device-id]/logs/fatal
homie/[device-id]/logs/error
homie/[device-id]/logs/warn
homie/[device-id]/logs/info
homie/[device-id]/logs/debug
homie/[device-id]/logs/trace

Improve documentation of setter

Improve with example the documentation about set

Proper getter and setter method

implement get and set for every property to request to send the property back

send homie/[device-id]/livingroom/light01/value/get "true"
receive homie/[device-id]/livingroom/light01/value "255"

send homie/[device-id]/livingroom/light01/value/set "128"
receive back homie/[device-id]/livingroom/light01/value "128"

Every "folder" needs to implement a $properties property?

Every parameter in the structure should include the $properties field?
for example the $fw parameter should be

homie/super-car/$fw/$properties → "name,version"
homie/super-car/$fw/name → "weatherstation-firmware"
homie/super-car/$fw/version → "1.0.0"

or the default level

  homie/super-car/$properties → "$fw,$protocol,$name....."

The other parameter should be optional and set to default value if not present

homie/super-car/$name → set by default as super-car if not present
homie/super-car/$settable → set by default as false if not present
homie/super-car/$datatype → set as string by default 
homie/super-car/$unit → set as empty by default
homie/super-car/$format → set as empty by default

another idea could be to separate the "$properties" from $hidden-properties

$properties = "name,lights,switch"
$hidden-properties = "$property,$cpu,$log"

In this way we could "navigate" every level

send

 homie/super-car/$properties/$get → "true"

receive back

  homie/super-car/$properties → "$fw,$protocol,$name....."

Split $homie property

$homie property could be split in

homie/super-car/$protocol/$properties → "name,version"
homie/super-car/$protocol/name → "homie"
homie/super-car/$protocol/version → "3.0.1"

This could permit to define other protocols similar to this

homie/super-car/$protocol/$properties → "name,version"
homie/super-car/$protocol/name → "nick"
homie/super-car/$protocol/version → "0.0.1"

Parameter to know if ota is supported

homie/super-car/$fw/ota-support → "true"

HW information channel Specification

homie/super-car/$hw/$properties → "cpu,board"

cpu

homie/super-car/$hw/cpu/$properties → "name,eeprom-size"
homie/super-car/$hw/cpu/name → "esp32"
homie/super-car/$hw/cpu/eeprom-size → "2048"

board

homie/super-car/$hw/board/$properties → "id,rev,manufacturer"
homie/super-car/$hw/board/id →  "SQW-LIGHT"
homie/super-car/$hw/board/rev → "A0.1"
homie/super-car/$hw/board/manufacturer → "ACME Industries"

Could also be reasonable to change the name from $implementation to $board or $hw-info

[ThomDietrich]

Hello @nicola-lunghi 👋
I think it would always be better to propose those as individual issues.
Anyhow, thanks for your feedback, I'll try to cover all points:

Log channel

Interesting point. Please open a separate issue.

Improve documentation

You and I agree, the documentation still lags a few details. Please feel free to open a PR! 👏

Proper getter and setter method

I didn't get your point. Are you talking about a way to query a value? If so there was a discussion on the idea in another issue. If everyone would separate their issues I may have found it just now... didn't 😕

Every "folder" needs to implement a $properties property?

Again a bit unclear to me. There are no folders. The idea of optional attributes and defaults is discussed in #48

navigate" every level ... send ... receive back ...

Be careful. MQTT does not follow the request-reply messaging pattern!

Split $homie property

Not meaningful. If a device doesn't follow the homie convention it doesn't follow the homie convention 🤡

Parameter to know if ota is supported

Sounds reasonable but I'd have to check the details. Please open a separate issue.

HW information channel Specification

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.

Thanks for your input. I hope I addressed all your ideas. Looking forward to your response.

[nicola-lunghi]

Thanks for your quick response (i will respond to you and split the issue in separate issues after work :-)

[nicola-lunghi]

see the other issues that I've created

#77
#78
#79
#80
#81
#82
#83
#84