On 26/08/2021 17:05, Patrick Wigmore wrote:
On Thu, 26 Aug 2021 14:10:31 +0100, PeterMerchant wrote:
Problem sorted, though I don't know why.
I took out the hyphens in the Pot-Left & Right strings, and made
them Pleft and Pright. and it does not crash.
Peter.
I don't know whether you are still interested in getting to the bottom
of this now that you've got it working.
Look at the subscriber-2 listing. It worked with hyphens, just to baffle me.
I've just had a look at your original message with the code excerpts
and I could not see anything that stood out to me as obviously wrong.
But I am missing a lot of context.
Here are some questions and suppositions I might put to myself if I
was trying to get to the root of why this was happening:
When does it crash? i.e. what part of the program is it executing when
it crashes. I'm guessing it crashes when the subscriber receives a new
message, rather than as soon as you try to run the program, but does
it crash for _any_ message, or only messages with particular payloads?
It seems to me that it crashes when it is started by systemd. There is nothing
useful in the error message. There must be something useful somewhere, but I
don't know where to look.
What (if any) traceback do you get when it crashes? That's probably
useful information.
I can't see anything useful in here. it refers to lines in other parts of the
python system.
I don't know what kind of object 'message' is, or what calls these
functions you've posted. That might be relevant.
'message' is a text string that is very free format in MQTT.
It could be that whatever code in the subscriber is creating the
message object is not handling the hyphens properly, or it is not
encoding the strings into exactly the format you expected.
I log into the Pi and run another instance of a subscriber for the same topic
like this:-
*mosquitto_sub -h 192.168.1.8 -v -t "rc-car-pwm/#" *
and it shows all the correct data, including the hyphens if they are part of
the message.
Maybe the hyphens are being converted into some other character
*before* getting sent over the message bus, or perhaps the byte
encoding is coming directly from the publisher and is not 100%
compatible with the encoding that the subscriber is expecting.
Are both the publisher and the subscriber written in Python? Does the
underlying CPU architecture affect the binary format for either one,
or is that all abstracted away for us?
No. The Publisher is a Wemos D1 ESP8266 chip and it is written in a 'c' type
language as used by the Arduino. I use the Arduino IDE vn 2 to program it.
Maybe more messages than expected are being sent and received. Perhaps
motorleft(), motorright(), etc, can't handle being called too
frequently.
Nothing happens fast. Each message is sent when the appropriate button is
pressed on the Wemos setup, and on the Analog reads of the Potentiometer I
notice a 500ms sleep before transmitting.
Quite far down this post
https://madsmaddad.blogspot.com/2020/10/arduino-uno-wemos-d1-mini-wifi-and-mqtt.html
is a picture of the Publisher controller. The 'slow' button has been replaced
by a pot. It didn't work as a button because I discovered rather late on that
it was connected to the analog input.
No worries if you are not going to dig any further into this.
Patrick
In MQTT I could have created a separate subscriber for each action. they would
then be rc-car-pwm/motorleft etc.
My current Pi software sets the PWM width to a set figure. long term i want to
send from the Publisher the PWM pulsewidth, and this would be another part of
the message, but I have a lot of learning to do first.
Thanks for your interest.
--
Next meeting: Online, Jitsi, Tuesday, 2021-09-07 20:00
Check to whom you are replying
Meetings, mailing list, IRC, ... http://dorset.lug.org.uk
New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
