thorrak / tiltbridge

Tilt Hydrometer to WiFi Bridge
http://www.tiltbridge.com/
Other
61 stars 27 forks source link

MQTT only one of three active tilts show. #206

Closed chrbratt closed 2 years ago

chrbratt commented 2 years ago

Has a problem with only one of three active Tilt hydrometers being sent as a telegram to my mqtt broker from Tiltbridge. I'm a little unsure and do not really know in which end I should start troubleshooting. So I thought I would ask the question here and see that tiltbridge really has support for sending info from several tilts at the same time. ?

thanks in advance

image

image

chrbratt commented 2 years ago

It send info for all three to Brewfather.

image

thorrak commented 2 years ago

Although I don't personally use MQTT, looking at the code, it should send all Tilts: https://github.com/thorrak/tiltbridge/blob/860a4bd0b4ef3c8ddafa3dc90bf971a853616746/src/sendData.cpp#L742

Not sure why you aren't seeing them come through - especially if they show up on both the main screen of TiltBridge and in Brewfather.

madsmooth commented 2 years ago

I only have a purple tilt and have not been able to get it to send any updates over mqtt. Any chance there isssie with some color codes preventing publish of updates?

thorrak commented 2 years ago

I only have a purple tilt and have not been able to get it to send any updates over mqtt. Any chance there isssie with some color codes preventing publish of updates?

That line of code I linked is the one that loops through all the colors, so it shouldn’t matter — but it’s possible there is something else going on that causes it to somehow matter.

If either of you have a spare ESP32 and don’t mind testing, there is a “tilt simulator” firmware I can push to BrewFlasher that will simulate all the colors of tilts simultaneously. Might be interesting to see if it’s the same colors dropping out

madsmooth commented 2 years ago

I only have a purple tilt and have not been able to get it to send any updates over mqtt. Any chance there isssie with some color codes preventing publish of updates?

That line of code I linked is the one that loops through all the colors, so it shouldn’t matter — but it’s possible there is something else going on that causes it to somehow matter.

If either of you have a spare ESP32 and don’t mind testing, there is a “tilt simulator” firmware I can push to BrewFlasher that will simulate all the colors of tilts simultaneously. Might be interesting to see if it’s the same colors dropping out

I have a spare and willing to test. Is there a way to view log output using the web view?

thorrak commented 2 years ago

Ah, hm. Unfortunately, unless you're comfortable compiling your own firmware it doesn't look like this will work, as it requires hardcoding your WiFi credentials. Let me see if I can get WiFiManager added in without too much effort.

thorrak commented 2 years ago

I've thrown some code together here without any testing whatsoever (other than to make sure it compiles) so I can't promise that this works, but if you either launch BrewFlasher or use BrewFlasher Web Edition you should see - under project "Other" board "ESP32" - an entry for "Tilt Sim v0.0.1". This is based off spouliot's tilt sim code, and you can see my changes here.

If it works, you'll see it spin up an AP named "TiltSimAP" with a password of "tiltsim". Log into it, connect it to your wifi, and it should begin to pretend to be every tilt.

If it doesn't work... say something here and I'll try to poke at the simulator code a bit tomorrow.

madsmooth commented 2 years ago

I have a second set of the TFT hardware configuration. I was able to flash the Tilt Sim via web flasher but never see an AP come up like you suggest. Any chance you built it for a different hardware or perhaps it shouldn't matter so long as it's esp32?

On Wed, Feb 16, 2022, 12:24 AM John @.***> wrote:

I've thrown some code together here without any testing whatsoever (other than to make sure it compiles) so I can't promise that this works, but if you either launch BrewFlasher or use BrewFlasher Web Edition https://web.brewflasher.com/ you should see - under project "Other" board "ESP32" - an entry for "Tilt Sim v0.0.1".

If it works, you'll see it spin up an AP named "TiltSimAP" with a password of "tiltsim". Log into it, connect it to your wifi, and it should begin to pretend to be every tilt.

If it doesn't work... say something here and I'll try to poke at the simulator code a bit tomorrow.

— Reply to this email directly, view it on GitHub https://github.com/thorrak/tiltbridge/issues/206#issuecomment-1041121436, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEUVNP6CGXIR5ZS4RA6KLTU3MYHRANCNFSM5OMW7EBQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

thorrak commented 2 years ago

I have a second set of the TFT hardware configuration. I was able to flash the Tilt Sim via web flasher but never see an AP come up like you suggest. Any chance you built it for a different hardware or perhaps it shouldn't matter so long as it's esp32?

The hardware shouldn't matter, but I wasn't kidding when I mentioned my changes to add the wifi config support were completely untested, so I'm not shocked it isn't working as expected. ;)

Let me test it later today and see if I can get that fixed

madsmooth commented 2 years ago

No worries. I did end up testing with the v1.0.2 old firmware and mqtt was sending updates for my purple tilt, when I updated back to v1.1 it did not work for me, despite using the same settings. Still happy to test anything in the future if you update the simulator.

On Wed, Feb 16, 2022, 9:14 AM John @.***> wrote:

I have a second set of the TFT hardware configuration. I was able to flash the Tilt Sim via web flasher but never see an AP come up like you suggest. Any chance you built it for a different hardware or perhaps it shouldn't matter so long as it's esp32?

It shouldn't matter, but I wasn't kidding when I mentioned my changes to add the wifi config support were completely untested. ;)

Let me test it later today and see if I can get that fixed

— Reply to this email directly, view it on GitHub https://github.com/thorrak/tiltbridge/issues/206#issuecomment-1041534216, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEUVNI57BRQ4PQXMZTAR3LU3OWMXANCNFSM5OMW7EBQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

thorrak commented 2 years ago

The simulator actually should work as is. The AP may not have spun up if you used firmware that cached WiFi credentials in the past on that controller (e.g. TiltBridge) but it likely connected to WiFi and is sending out BLE iBeacon signals as if it is a bunch of Tilts. You can verify by launching the tilt app on your phone if you have it - the app will show them all.

I took a look at the changes to the MQTT code between 1.0.2 and 1.1.0 and unfortunately don't see anything jump out that would cause any errors. The MQTT keepalive setting was reduced (initially it was expressed in milliseconds, but the standard wants it expressed in seconds) -- but this shouldn't result in individual colors being skipped. Additionally, a "uniq_id" field was added to the Home Assistant autodiscovery MQTT messages -- but these aren't the messages you are (or should be) looking at/missing.

pletch commented 2 years ago

Just a guess but is it possible that the MQTT buffer is now just a bit too small for the longer color names when attempting to publish the HA discovery payloads? I think overflowing this buffer will cause a MQTT client disconnect and the code only checks for connection on the first pass through the loop for the 3 topics for each color.

The MQTT buffer size is set here: https://github.com/thorrak/tiltbridge/blob/v1.1.0/src/sendData.cpp#L10

I don't have a unit to replicate the issue on or I'd help track this down.

madsmooth commented 2 years ago

So now I understand what you mean. I tested with the old and recent tiltbridge firmware and it was sending out 8 colors of mqtt messages including homeassistant auto discovery messages and data messages.

I did notice the simulator has 16 tilts, 8 regular and 8 pro or HD in each color but the bridge only identifies 8 colors, and it seemed like it was sending a single message for each despite reporting from different simulated devices. This may be how tiltbridge was designed so no issue from me.

I turned off the simulator, rebooted tiltbridge and cleared mqtt broker titlebridge message cache and tested again with nothing but my my real purple tilt and now it works. Unfortunately I can't tell you why it didn't work and now it does.

On Wed, Feb 16, 2022, 2:40 PM John @.***> wrote:

The simulator actually should work as is. The AP may not have spun up if you used firmware that cached WiFi credentials in the past on that controller (e.g. TiltBridge) but it likely connected to WiFi and is sending out BLE iBeacon signals as if it is a bunch of Tilts. You can verify by launching the tilt app on your phone if you have it - the app will show them all.

I took a look at the changes to the MQTT code between 1.0.2 and 1.1.0 and unfortunately don't see anything jump out that would cause any errors. The MQTT keepalive setting was reduced (initially it was expressed in milliseconds, but the standard wants it expressed in seconds) -- but this shouldn't result in individual colors being skipped. Additionally, a "uniq_id" field was added to the Home Assistant autodiscovery MQTT messages -- but these aren't the messages you are (or should be) looking at/missing.

— Reply to this email directly, view it on GitHub https://github.com/thorrak/tiltbridge/issues/206#issuecomment-1042094716, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEUVNK75RSZ75XMN6AOGUTU3P4S7ANCNFSM5OMW7EBQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

madsmooth commented 2 years ago

You must be on to something. If I increase my mqtt topic more than 8 characters I get no mqtt traffic.

On Wed, Feb 16, 2022, 4:41 PM Tim @.***> wrote:

Just a guess but is it possible that the MQTT buffer is now just a bit too small for the longer color names when attempting to publish the HA discovery payloads? I think overflowing this buffer will cause a MQTT client disconnect and the code only checks for connection on the first pass through the loop for the 3 topics for each color.

The MQTT buffer size is set here: https://github.com/thorrak/tiltbridge/blob/v1.1.0/src/sendData.cpp#L10

— Reply to this email directly, view it on GitHub https://github.com/thorrak/tiltbridge/issues/206#issuecomment-1042336612, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEUVNOHACL2THASVSRY3O3U3QKYRANCNFSM5OMW7EBQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

thorrak commented 2 years ago

Changing this is trivial - I'll get a test version out later tonight. Thanks @pletch !

thorrak commented 2 years ago

The test version is live. It's the v1.1.1 "beta" versions in BrewFlasher.

chrbratt commented 2 years ago

Many thanks for all the commitment regarding this. Will test immediately when I get home from work. Unfortunately I do not have an spare esp32 to test the tilt simulator on, but I have 3 active tilts that transmit, so it is easy to test.

I'll give you feedback here during the evening. :)

chrbratt commented 2 years ago

It worked directly on the first test. :)

image

Many thanks!

thorrak commented 2 years ago

Perfect! I'm going to reopen this for now until I can get this merged into master just in case anyone else has this issue before then, but hope to get this merged shortly.

Thanks again @pletch for identifying the fix!

chrbratt commented 2 years ago

One more thing on this subject. HA finds and auto discover temp sensors for each individual tilt but not SG.

image

image

This works and is auto discovered. _homeassistant/sensor/tiltbridge_tiltBlueT/config { "dev_cla": "temperature", "unit_of_meas": "°C", "ic": "mdi:thermometer", "stat_t": "tiltbridge/tilt_Blue", "name": "Tilt Temperature - Blue", "val_tpl": "{{value_json.Temp}}", "uniq_id": "tiltbridge_tiltBlue" }

This isn't _homeassistant/sensor/tiltbridge_tiltBlueG/config { "unit_of_meas": "SG", "stat_t": "tiltbridge/tilt_Blue", "name": "Tilt Specific Gravity - Blue", "val_tpl": "{{value_json.SG}}", "uniq_id": "tiltbridge_tiltBlue" }

_tiltbridge/tiltBlue { "Color": "Blue", "timeStamp": 10538, "fermunits": "SG", "SG": "1.0160", "Temp": "13.3", "tempunits": "C" }

thorrak commented 2 years ago

Unfortunately, I have run into that issue with another project, and haven't yet found a solution. If I find a solution (other than splitting the MQTT messages) I'll backport it to TiltBridge.

pletch commented 2 years ago

@thorrak, I got curious about the autodiscovery issue and spun up a virtual machine to evaluate. Testing with mosquitto_pub / mosquitto_sub along with a home assistant core installation, I was able to get it to work. I think the example here is malformed and this is why it doesn't work.

If the discovery topics and messages are formatted as such, it will create both entities: Temperature Discovery Topic: _homeassistant/sensor/tiltbridge_tiltBlue/temperature/config Message: { "dev_cla": "temperature", "unit_of_meas": "°C", "ic": "mdi:thermometer", "stat_t":"tiltbridge/tilt_Blue", "name": "Tilt Temperature - Blue", "val_tpl":"{{value_json.Temp}}", "uniq_id": "tiltbridge_tiltBlueT", "device": { "identifiers":"blue", "name":"Tilt Blue" } }

Specific Gravity Discovery Topic: _homeassistant/sensor/tiltbridge_tiltBlue/specgrav/config Message: { "unit_of_meas": "SG", "stat_t": "tiltbridge/tilt_Blue", "name": "Tilt Specific Gravity - Blue", "val_tpl": "{{value_json.SG}}", "uniq_id": "tiltbridge_tiltBlueG", "device": { "identifiers":"blue", "name":"Tilt Blue" } }

Note that each entity must have its own uniq_id as well so I appended T or G accordingly.

There may be a way to get it to group the two entities under a single Tilt Blue MQTT discovered device but I am not sure how to do it at the moment.

Edit: Adding the device key above in the message payload will group the sensors under a single Tilt Blue device.

mqtt-discover2

mqtt-discover

chrbratt commented 2 years ago

Wow, that did it @pletch! @thorrak is it possible to get these changes in a test version.?

pletch commented 2 years ago

@thorrak, I can set up a test install on a few ESP32s and push over a PR with some proposed updates if you don't have time to look at this. LMK.

thorrak commented 2 years ago

I just re-released v1.1.1 to incorporate this change as well. Thanks again for tracking this one down - I appreciate it!