Use Homie Settings before Homie Setup?

[timpur]

Is it possible to use homie settings before homie is setup.

Id like it use this to set a parameter used fro advertising a node attribute (which has to be done before homie setup...).

Thanks Tim.

[timpur]

Also wondering if its possible to set settings through code during running of homie with out going through mqtt?

[euphi]

Yes, it is possible. But be careful when you use settings within a constructor (or anything called from a constructor) of a global or static object. See PR #335 for a solution to use HomieSetting in a constructor.

[timpur]

@marvinroger, ideas?

[marvinroger]

The problem is we're populating the settings objects at setup time. Introducing another method might be a solution, but we would have to refactor a bunch of things, but that's definitely a valid use case. Let's put this on 2.1.0 roadmap (as 2.0.0 is not even published final.. school, again and again 😕).

Sent from my Google Nexus 5X using FastHub

[euphi]

Ah, yes. My PR #335 just makes it possible to add items to the vector IHomieSetting::settings before main() (and thus the 'global' setup()) , but the value of the HomieSetting is read during Homie::setup().

[timpur]

school, again and again

I get that, in the same boat.

TBH dont know much about the internals of homie, ill slowly learn how it all works so i can make more meaningful contributions. Thus dont really know what you guys are talking about sorry :P

[timpur]

Could we have a Homie.loadSettings() which loads the config? then use Homie.setup() like normal, but the load config part is optional thus, not interfering with the current workflow? (Homie.setup() would call Homie.loadSettings() if not been called, obviously...).

Can you extract that part of the settings config code and use the settings objects like that, all before Homie.setup()?

[euphi]

BTW: @marvinroger Can you merge my PR soon? It just changes a undefined (or random) behaviour to a defined one.
I need the PR for my HomieNodeCollection, so for now I use my own fork, but this means to not update that often. It also complicates using platformio / travis.

[luebbe]

I've beed struggling with this a lot. I'm subclassing Homie nodes which have custom properties. Example a Weather Underground Node that needs an API key, location etc.
When I set the properties' default values in SubclassedNode.setup() or in SubclassedNode.setuphandler() , which is called via Homie.setSetupFunction(), they override the settings that Homie has already read from the config.

See log:

• OTA - Display
• OTA - Setup done
💡 Firmware display (1.0.0)
🔌 Booting into normal mode 🔌
{} Stored configuration
  • Hardware device ID: a020a6117237
  • Device ID: a020a6117237
  • Name: Display
  • Wi-Fi:
    ◦ SSID: onklan
    ◦ Password not shown
  • MQTT:
    ◦ Host: 192.168.0.10
    ◦ Port: 1883
    ◦ Base topic: homie/
    ◦ Auth? no
  • OTA:
    ◦ Enabled? no
  • Custom settings:
    ◦ WuApiKey: xxxxxxxx (set)                       <--- Yeah correct properties are read
    ◦ WuLanguage: DL (set)
    ◦ WuCountry: DE (set)
    ◦ WuCity: MyTown (set)
WundergroundNode Setup                               <--- called from Homie.setup()
↕ Attempting to connect to Wi-Fi...
✔ Wi-Fi connected, IP: 192.168.0.207
Triggering WIFI_CONNECTED event...
↕ Attempting to connect to MQTT...
Sending initial information...
✔ MQTT ready
Triggering MQTT_READY event...
Calling setup function...
Setuphandler
WundergroundNode Setuphandler                         <--- called from Homie.setupHandler()
〽 Sending statistics...
  • Wi-Fi signal quality: 70%
  • Uptime: 11s
Requesting URL: /api/YOUR_API_KEY/conditions/lang:EN/q/UK/YOURTOWN.json        <-- uses wrong defaults, because they are overwritten in setup() setuphandler()
start document
Requesting URL: /api/YOUR_API_KEY/forecast10day/lang:EN/q/UK/YOURTOWN.json

My solution is that I have introduced a beforeSetup() method, that I call from main setup before Homie.setup(). The log then looks like this.

• OTA - Display
• OTA - Setup done
WundergroundNode Before Setup                    <--- called from main setup() before Homie.setup()
💡 Firmware display (1.0.0)
🔌 Booting into normal mode 🔌
{} Stored configuration
  • Hardware device ID: a020a6117237
  • Device ID: a020a6117237
  • Name: Display
  • Wi-Fi:
    ◦ SSID: onklan
    ◦ Password not shown
  • MQTT:
    ◦ Host: 192.168.0.10
    ◦ Port: 1883
    ◦ Base topic: homie/
    ◦ Auth? no
  • OTA:
    ◦ Enabled? no
  • Custom settings:
    ◦ WuApiKey: xxxxxxxx (set)
    ◦ WuLanguage: DL (set)
    ◦ WuCountry: DE (set)
    ◦ WuCity: MyTown (set)
    ◦ MqttTopic: homie/a020a611f230/indoor/# (set)
StatusNode Setup
MqttNode Setup
Topic:homie/a020a611f230/indoor/#
WundergroundNode Setup
↕ Attempting to connect to Wi-Fi...
✔ Wi-Fi connected, IP: 192.168.0.207
Triggering WIFI_CONNECTED event...
↕ Attempting to connect to MQTT...
Sending initial information...
✔ MQTT ready
Triggering MQTT_READY event...
Calling setup function...
Setuphandler
WundergroundNode Setuphandler
〽 Sending statistics...
  • Wi-Fi signal quality: 72%
  • Uptime: 11s
Requesting URL: /api/xxxxxxxx/conditions/lang:DL/q/DE/MyTown.json   <--- Success :)
start document
Requesting URL: /api/xxxxxxxx/forecast10day/lang:DL/q/DE/MyTown.json
start document

[timpur]

Any progress on this ?

[timpur]

Added in v2.1 (not yet merged)

Example of use (also in docs)

HomieSetting<long> percentageSetting("percentage", "A simple percentage");

void SetupHomieSettings() {
	percentageSetting.setDefaultValue(50).setValidator([](long candidate) {
		return (candidate >= 0) && (candidate <= 100);
	});

	Homie.getLogger() << "percentageSetting Value: " << percentageSetting.get() << endl; // should be default

	Homie.loadSettings();

	Homie.getLogger() << "percentageSetting Value: " << percentageSetting.get() << endl; // should be config value
}

I generally setup settings before nodes so i can use setting values in the setup of nodes. (this will make that even more possible !!!!)

[stritti]

Seems to be stale issue.
Will be closed.
Feel free to reopen if there are more information.