ESPHome Component for EmonTX (ESPx & PiPicoW)

Hardware emonESP
62

Well, I’ll bother again !
With the current implementation, the yaml would look like this:

http_request:
  id: my_http
  verify_ssl: False

mqtt:
  id: my_mqtt
  broker: test.mosquitto.org

emontx:
  emoncms:
    http_id: my_http
    server: http://192.168.1.2
    node: 2
    apikey: !secret emoncms_apikey
  mqtt_forward:
    mqtt_id: my_mqtt
    topic_prefix: emon/emontx

I’m not really used with mqtt…

Instead of publishing something like emon/emontx4/P1, we could publish this way emon/emontx4/power/P1, same for voltage, …
Would it be compatible with emoncms ?
“Pulse” would be in the same sub-topic as “E1…”. So emon/emontx4/energy/pulse

63

For emoncms, it is fine (and preferable) to simply publish the data as a single JSON string.

Perhaps the option to break the MQTT into separate topics could be offered?

I’d keep it simple with emon/emontx4/P1, ...P2 etc. Don’t think it needs the intermediate power topic.

64

Hi @borpin ,

Well, may be I didn’t write properly what I wanted to explain, lol ! Sorry, I’m french, my english may not be perfect :smiley:

For now, each sensor is published as a separate topic AND the full original json is published under emon/emontx4/data

65

It is really very good!

Can you publish the JSON to emon/<device_name> (no data sub topic) - translates better to emoncms. (I think this needs added to the docs).

Also for MQTT, it might be better for the user to specify just the ‘base’ topic (e.g. emon) and then state in the docs what is then added by the component. So it would add device_name - JSON published on this, then device_name/P1 for CT outputs.

I think the option to send JSON, and/or split data would be good.

Perhaps also to override the device_name in the topic as well.

Does the node need to be a number? I think emoncms accepts names as well (need to check that).

66

I am getting a parse error when trying to put the API key in both directly and as a secret.
Ignore that - user error

67

Thx :wink:

Sure, I’ll fixed it.
But we should remember, that this MQTT stuff isn’t exclusively intended for forwarding to emoncms. I see it much more as the new feature, so anybody who runs another system like Jeedom, … will be able to easily integrate OpenEnergyMonitor devices into their system.
My knownledge in “MQTT best practices” are near zero :smiley:

I can add some more details in the mqtt section, that’s not a problem. We could make it full flexible, trying to not overcomplicate it either.
I though about a sub-topic power, voltage, … because this way, it’s easy to filter out what the user wants. Again, I could define a parameter like “group” or “categorize”, or something like that.

No, that’s pure copy-paste from some doc.

1 Like
68

Thanks. Having some issues getting a config to work. Not seeing anything on the HTTP input to emoncms.

logging - Can you add in more logging, please? I’ve enabled VERY_VERBOSE but not seeing anything. For HTTP, what is the URL used for instance.

Cannot configure the mqtt section

Failed config

emontx: [source /config/esphome/emontx-2.yaml:59]
  
  [mqtt] is an invalid option for [emontx]. Please check the indentation.
  mqtt: 
    topic_prefix: emon/emontx
    mqtt_id: emontx_mqtt
  emoncms: 
    server: http://192.168.7.145/
    node: 10
    apikey: !secret emoncms_apikey

Config

mqtt:
  broker: 192.168.7.50
  id: emontx_mqtt

emontx:
  mqtt:
    topic_prefix: "emon/emontx"
    mqtt_id: emontx_mqtt
  emoncms:
    server: http://192.168.7.145/
    node: 10
    apikey: !secret emoncms_apikey
69

Agreed :slight_smile:. For emoncms, the JSON is the best format and if you do both, you will get duplicate data in emoncms (just realised this :frowning: ) .

Could you add to the docs that this is a digit or a name? The example may be better as a name :slight_smile:

1 Like
70

Having the TX&RX the right way round will help…

Getting data now and getting logging!

2 Likes
71

Ah, should be mqtt_forward: - docs need an update @FredM67 :slight_smile:

72

Ok sorry…let’s simplify it and, as the doc writes… let use mqtt

1 Like
73

By fixing, I saw that the doc was mixed up! Sample with mqtt, blabla with mqtt_forward !

1 Like
74

MQTT worked with mqtt_forward then I tried a recompile and it started complaining about mqtt_id

tried with mqtt and still doesn’t like it :frowning:

Compiling if I use mqtt and remove the mqtt_id

Can it work with multiple MQTT brokers?

75

Well, that was the point in fact. Since this component is implemented as a “singleton”, it’s not present or it’s instantiated only once. There is no way to declare multiple brokers.
From there one, there’s no need to specify any mqtt_id.
For http forwarding, it’s the same.

Sorry, for this chaos!

1 Like
76

No bother. So no option to send to multiple MQTT or HTTP end points? Not an issue; just checking :slight_smile:

77

Looking at my emoncms inputs from the MQTT side, definitely want the option to make it JSON (on the base topic) or separate topics :slight_smile:. Defaulting to JSON would be my preference. I cannot envisage a situation where both were required (so it does probably exist).

1 Like
78

That’s right…
At most one http_request and/or at most one mqtt client.

1 Like