Create menu with buttons to tap when motion detected

Michael · 15 January 2024 20:42

Ah I see - i interpreted this part

to mean that your whole code hangs for minutes at a time - but I think you were referring to the actual MQTT transaction round-trip. Which is pretty unusual! MQTT ought to be near-instant.

It’s worth a try! I’m not sure how the adafruit library uses the QOS settings - i thought they were more a call-response type of behaviour to guarantee QOS. If the initial publish takes very long to complete then it may not make a difference.

Let us know how you go

Tom252062 · 15 January 2024 21:22

Oh yes, my mistake - I should’ve explained further. I’ve watched my mosquitto MQTT logs in these instances of delays, and can confirm it doesn’t leave the unit for X minutes, and by the time the log shows the MQTT command come through, the action (ie lamp on/off) has just completed. Also the unit screen stays on sometimes for a few minutes during these delays (ie. doesn’t turn off after 15 seconds of not tapping), which suggests to me the MQTT command hasn’t left the unit yet or is still processing it. It does seem odd that such a simple program takes so long… wifi remains at around -45 to -55dBm and still seeing same delays when I’m sitting right under the access point too, and I’ve just used 9 alpha firmware after updating some libraries which I thought also could help but no luck. I’ll try the QoS level 1 or 2 and advise!

Pixmusix · 15 January 2024 23:24

Hi @Tom252062
May I clarify that this line below is where the program is hanging?
client.publish(button_message[touched], data)

Tom252062 · 17 January 2024 00:34

Hey @Pixmusix yes, I’m certain that’s where its hanging. The button status doesn’t even change (ie show as ‘pressed in’) until the MQTT command goes. So sometimes I’ll tap a button, it wont change to pressed in, and then say 2 minutes later it’ll ‘press in’ then the MQTT message goes, and screen turns off 15 secs from that point.

Pixmusix · 17 January 2024 01:05

I was reading these two thread below.

github.com/knolleary/pubsubclient

MQTT client.publish, How do I publish a string?

opened 03:44AM - 22 Sep 17 UTC

closed 10:01PM - 22 Sep 17 UTC

SteveRMann

I am not a seasoned C programmer, knowing just enough to usually figure things o…ut. But I am running into a problem with MQTT pubsub, specifically client.publish. I can publish ("topic","payload") all day long, but when I try to publish a string variable for the payload, I get errors that are way beyond my pay grade. //Global Variables String payLoad; //In loop() //This is pretty straightforward, if val is 1, I want to publish "on", and if 0, publish "off". //Sounds simple? if val == 1{ payLoad="on"; }else{ payLoad="off"; } client.publish("garden/light",payLoad); The error: "no matching function for call to 'PubSubClient::publish(const char [13], String&)'" The workaround is, of course, to just publish the literal string in the payload: if val == 1{ client.publish("garden/light","1"); }else{ client.publish("garden/light","0"); } But I am mysterified as to why I can't send a string to client.publish(). What am I missing here? Thanks

github.com/eclipse/paho.mqtt.python

publish blocks entire program

opened 08:26AM - 11 Dec 20 UTC

mhechthz

Type: Bug Status: More info needed

I have a really difficult problem. I'm using paho-mqtt inside python 3.7 on …mosquitto broker at an ubuntu 18.03 system. The program is a bridge between two brokers (which could surely be solved via mosquitto directly, but I did it this way). One special defined publish command of one client object irregularely hangs the entire program, i.e. starts but doesn't come back. Even timer events are blocked. The only solution is to kill the program from outside. The command itself is obviously ok, since I can send a hundred of publishes without problem. Also try-catch doesn't help, since the pogram hangs. No other publish command of both client object in the program shows this behaviour. Is there any chance to analyze what happens? EDIT: I added a threading.Semaphore() on friday - during weekend all seemed to be stable. Migth this be a hint? EDIT2: Also with semaphore the call to publish blocks / hangs the program.

I think something to try is building the “Fixes” branch of the repo.
It’s 4 commits ahead of master.

Tom252062 · 18 January 2024 20:52

Thank you! I’ll look into this and let you know how I go

Tom252062 · 19 April 2024 10:01

Hi all just to round this out - it works 95% of the time. I think its my wifi which isnt; awesome. I suspect

I am looking at a way to install openhasp on the titano (somehow) in place of this, as it seems more stable, but the code above should work for others!