Why not program them per the MQTT discovery documentation to work with Auto discovery? That’s what I do. I use my own firmware on all my esp sensors
That would be ideal. What framework do you use? I have a project on a Raspberry Pi which I’ve put Paho on and I have manually configured it just fine. That’s probably why manually configuring the Tasmota is driving me nuts. I will want to do a few Arduino as well: they’re a touch less expensive. If you have a recommendation for software that’s be great
100% correct. In fact, in developer tool states, it’s created an entity “S20_01_2”. Presumably that’s because S20_01 is already in the entity registry historically? Even so, it’s showing as unavailable.
When I crack this, it’s is going to be amazing, but right now, it’s soul destroying.
What do you mean by framework? I write c++ and push it to my esp chips OTA. It’s all custom firmware I wrote
Nice. I’ve used paho on the Pi to publish some temperatures from my garage. For the Arduino, I figured on using Nick O’Leary’s pubsubclient or maybe a hack to Tasmota or espurna.
OK, you are referring to libraries.
#include <Arduino.h>
#include <ESP8266WiFi.h>
#include <Wire.h>
#include <Adafruit_BMP085_U.h>
#include <PubSubClient.h>
#include <Adafruit_Sensor.h>
#include <ESP8266mDNS.h>
#include <ArduinoOTA.h>
#include <ESP8266HTTPUpdateServer.h>
#include <ESP8266WebServer.h>
#include <ArduinoJson.h>
Those are my standard libraries on most of my sensors.
Do you know of a way I can scrub the database, history, logs, entity registry, everything, so it effectively looks like a have a fresh install? I can publish topics from a Raspberry Pi and subscribe to them in HA, no problem, but I can’t seem to get HA to subscribe to a topic published by a Tasmota device.
I must have done something stupid earlier.
I’ve just tried to create a new sensor which should have returned me the Wifi strength fro my 4333MHz bridge. Same problem. I also tried to return the {{value_json.rfreceived.data}} from my RF bridge, to see which button was being pushed, but this also reads as unavailable.
Delete the DB file. Delete the log file. Empty the registry files.
This really seems like you dicked something up on the Tasmota firmware, and perhaps set a wrong option or setting. I don’t know the firmware, never messed with it.
Normally, that’d be me. This time, just for once, I used the official prebuilt binary.
So why are you deadset on using manual mode and not discovery? I moved all of mine over to discovery for ease of use
1 Like
I’m absolutely not dead set on it. I want to add a Wifi signal string sensor. Adding the Wifi sensor didn’t work and I wondered if it might have been because HA wasn’t subscribing, or the broker wasn’t passing the messages, so I decided to try t manually add the switch. Since I can’t even add a simple switch, that’s probably for the same reason that I wasn’t able to add a Wifi sensor. Now, I’m just struggling to pinpoint the reason.
- The broker is evidently OKay, or else the auto-confg wouldn’t work.
- HA is probably OKay, else the cards wouldn’t be working after auto-config.
So, I’m tending towards Tasmota as the problem. Out of curiosity, I just downgraded my S20 to 6.2.1 (stock prebuilt binary), deleted HA log, db, all registry entries, and integrations.
No change. Zip. Can’t manually add the Wifi sensor.
Right. I’m back at the starting blocks. I’ve auto discovery enabled. S20 working fine. Switching on and off happily from a lovelace card. “on” causes the following traffic on my MQTT sniffer:
s20_01/cmnd/POWER ON
s20_01/stat/RESULT {"POWER":"ON"}
s20_01/stat/POWER ON
So, I go to my configuration.yaml file and I add:
sensor:
- platform: mqtt
state_topic: "S20_01/tele/state"
name: "SocketRSSI"
unit_of_measurement: "%"
value_template: "{{ value_json.Wifi[0].RSSI }}"
payload_available: "Online"
payload_not_available: "Offline"
Sure enough, sensor.socketrssi has appeared in the dev-state screen, but with the status “unknown”. Even if I switch on the S20 (thereby causing it to broadcast the state messge) it’s still “unknown”.
The sensor.socketrssi does not appear int he entity registry. But this is properly weird: the S20 switch doesn’t appear in the entity registry, either. In fact, the switch isn’t in the Integrations/MQTT.
I’m lost.
Well, I just used loads and loads of very rude words. Some of them, I didn’t even know what they meant.
You know the way topics are case sensitive? I hadn’t spotted this, but over on Tasmota forums, someone suggested that “/state” should be “/STATE”. Well, that didn’t work, but I persisted in messing around with it today.
The socket wouldn’t add as a device because I had called it “S20_01” and then subscribed to “s20_01”.
I’ve been beating myself up for weeks over this. You guys, too. I’ll sleep better tonight.
Those aren’t the same
Indeed. One is a topic subscription and the other is a set of traffic between two happy devices.
I’m not sure what you’ve spotted, but I’ve spotted that “s20” and “S20” are different. So everything I’ve been moaning about over the last 2 weeks is fixed. Even the completely unnecessary manual setting up of the switch.
Thanks for looking.
I was simply referring to incomplete data here.
OK. That’s what I would expect them both to be.
No idea what this means. 2 devices should be communicating over the STATE and COMMAND topics on MQTT
I’m glad you got it sorted, but from what I was reading, you weren’t comparing apples to apples.
You’re right. I just did a repeat. When HA turns on my auto detected S20, this is the traffic I see on my MQTT terminal when I subscribe to all. I wonder what’s going on there. I was so relieved, I didn’t even give it a second thought.
No, I see how that could be read. You’re quite correct. It wasn’t supposed to be a comparison; rather an illustration that it was actually working and that I wasn’t going nuts!
Again, thanks for the pointers to date.