I’m really confused - has something changed recently (since September) with particle subscribe/publish?!
I made a TINY tweak today to a Photon I have here at home translating Particle Pub/Sub to MQTT (basically adding in a single new command) and that caused some of the existing translations (which have been stable for a year+) to go screwy. So I rolled back the change to my last known working config, going back to the year old config, and now that doesn’t work either?! Truly bizarre.
So basically what’s happening is my Particle nodes dotted about the house are transmitting their Particle Publish messages as normal.
The translating Photon (between Particle pub/sub and MQTT) is seemingly NOT translating Particle Pub Sub to MQTT anymore.
The translating Photon IS still translating MQTT to Particle Pub/Sub?!?!
This is very, very odd. I’m using Chrome’s MQTTBox to monitor what is going on on the MQTT side and of course the console to monitor on the Particle side. I’m generating a few Particle publishes from the API as well and they’re just not being translated by the Photon anymore into MQTT.
We’d need to see some code and also a clearer definition of what “not translating” is supposed to mean?
Are you sure the “translation” fails or could it rather be that the Photon just doesn’t transmit the MQTT messages correctly?
You should also add some Log statements to get a clearer picture of what’s going on inside your subscribe handler when it receives an event, what it makes of that event and what it tries to forward to the MQTT broker.
Also, do you see the all the expected events in console?
Hi ScruffR - thanks for the help - tearing my hair out at the moment so it’s very welcome.
It could well be that the Photon isn’t transmitting the MQTT messages correctly or at all. In fact, that’s exactly what seems to be happening as far as I know.
I see in the Particle console all of the publishes I am publishing using the API, but I’m not seeing ANY Particle publishes which have come about as a result of an MQTT message hitting the Photon.
Since you’ve asked to see some code, If it’s OK, I’ll send you a direct message link to a pastebin with my code, I’m more than happy for any error to be posted here in isolation, but I’d rather not have the whole code here if I can avoid it?
This is truly, truly bizarre. I can’t understand why what worked yesterday isn’t working today - the only difference is the code is freshly flashed to the Photon.
Hi Scruff, not with any of my Photons, no. And my Rosetta/translating device is a Photon.
The only time I ever target older firmware versions is where none of my Cores can cope with the newer firmware because of the combined space needed for the newer firmware plus my code exceeds the space available on the Core.
I’ll happily try to target an older firmware version (it would need to be an early september 2019 firmware version) HOWEVER does this theory (which is the most promising so far!) still hold water given that even when I reflashed an already compiled, known working file to the Photon, it STILL didn’t work? Could that be because the firmware is added by the flashing process?
If a change in Particle’s firmware has caused some of my code to stop working, should I possibly be able to find a warning in a changelog somewhere? Sorry for all this panicking I’m just surprised that restoring to an older backup hasn’t restored functionality…!
So your Photon was already 1.4.2 before you applied this new code or you were compiling this new code agains the older version on your Photon?
Yes. If your latest application caused a device OS update your previous code would still run with that latest device OS framework even when compiling it against an older target. Flashing "older" firmware will not downgrade the device OS (unless we are talking about Cores).
There were some recent changes in device OS that may break exisiting code but these usually result in SOS panic crashes
To name the two most "problematic"
some actions are not allowed in object constructors anymore due to non-deterministic order of execution
dynamic memory stuff is not allowed in ISRs anymore
But neither of these seems to apply to your code.
BTW, I have replied to your PM with some suggestions for your code.
No my Photon would have been running 1.2.1 prior to me flashing the new code to it. This morning I tried to do a compile --target 1.2.1 which the compiler said it was doing, but when I look at the Photon in Console view it says it's still running 1.4.2 - so it doesn't appear to have downgraded the firmware - is that because of this
or does that only apply if you've not used the --target flag?
IS there a way to target older firmware on the Photon and insist on downgrading the device OS?
You need to distinguish between the device OS version and the application version.
A lesser version application will not cause a downgrade of the device OS.
This can be seen by running particle serial inspect in Listening Mode.
Thanks Scruff. I’m not near the device at the moment so I’m trying to do all of this OTA.
I have tried to go from 1.4.2 to 1.2.1 by downloading the binaries and flashing first photon-system-part1@1.2.1 then photon-system-part2@1.2.1 to the device. Both were accepted and both were ‘successful’ apparently but the device firmware version as seen from the console remains unchanged as 1.4.2.
Do I need to go back to 0.7.0 to then upgrade to 1.2.1?
Ignore that! After a couple of minutes the firmware on the console changed and the device seems to be doing what it’s asked to again!
Further checks ongoing as I type…
WOOhooo!! (Potentially?!)
So can I AVOID the device automatically upgrading itself (until I figure out what the new firmware doesn’t like) by targeting a firmware version when compiling?!
Thanks so much for getting in touch. And yes, I agree with you, Scruff IS amazing.
I guess I am confused about what might have broken between 1.4.2 and 1.2.1 - and I think Scruff was saying the key to possibly finding out might be a serial connection to the Photon and some log trace action.
In the meantime if you’re also curious about potentially identifying a hitherto unknown breaking change I’d happily ping over my pastebin…
At the MOMENT pending a bit of testing it looks like Scruff and his downgrade might have sorted me out!
Obviously mid and long term I’d prefer NOT to have to target a specific point in firmware time.
I agree that this is not a longterm solution, so here’s what I recommend:
When you have physical access to the device (or any test device with this code) please let me know.
We’ll address the update path with a bit of a safety blanket in place and we can go through and make sure your firmware is compatible with our recent DeviceOS!
EDIT- for clarification, my suspicion is that something is/went awry with the flash process and the concurrent upgrade, not that there’s an incompatibility. Troubleshooting this is a lot easier when proximal to a given device (eg. seeing what Status code is flashing etc).
And just to confirm, from what I can see from ‘afar’, the “rosetta” functionality of my Photon is restored - it’s converting from Particle Pub/Sub to MQTT and visa versa, so when I go home for lunch I’ll just check that the other bits and pieces the device is doing (DfPlayer Mini and reading a few I/O) works too, if so, sounds like massive stress over!
