Sadly it looks like there is a swiftui bug too, but at least the full swipe seems to continue work after fixing my bug.
I tried this in the new version. There is still the same problem with the swipe/ disconnect functionality. It only happens after going to the messages screen.
Yeah seems to be a bug with swipe actions and a navigation view. I did have a bug that made it worse so at least you seem to eventually be able to full swipe to delete it.
Not on my iPad. I can swipe and the red appears but itās gone before I can press it. Iāve tried and tried to be super quick, but thereās no way to do it as far as I can see.
Iām not sure what you mean by āfull swipeā. Iāve tried doing very long slow left swipes too. The red part grows to be half the button, but it then disappears and doesnāt disconnect.
There are actions for touching the buttons when they appear, and full swipe across the item which does the first (and only in this case) button action
https://developer.apple.com/documentation/swiftui/view/swipeactions(edge:allowsfullswipe:content:)
I have updated to the latest 1.2.46 on two tbeams with platformio. I have disabled sleep following @thebenternās PowerFSM.cpp mod. With two tbeams connected to two iphones (both running latest version). Can I just check - the primary channel does not broadcast to itself - only to the other nodes meshed? I see specfic messaging only to the āotherā device. Is this right? Thanks. Does look good although on my iphone the remove node still does not work.
Not sure I totally understand what you mean by broadcast to itself?
The messaging should send and receive messages on the primary channel, though I am seeing some issues and reports of the devices not always being subscribed to all the updates from the mesh, including new messages.
Hi - apologies for being too brief. I meant that with two tbeams in my mesh if I send a message it does not appear on both tbeams only the tbeam not bluetoothed to my phone. This does make sense and it seems consistent - it has done the same this morning after my phone updated to the latest version. So I do not think itās a missed message.
Just to say that using sleep disabled is very good for ease of connection and last heard seems to update a lot more. But battery life is only about 12 hours. So okay for day hike.
I just added three more tbeams to the mesh (all with disabled sleep). Now all the tbeams receive a message except for the tbeam from which the message is sent. I will keep testing today.
Hi @garth I have noticed one thing. I am running the latest version and set a preferred radio. This radio then disappears from my radio list on the bluetooth menu. If I subsequently lose connection I cannot re-connect because the radio does not re-appear in the list. I have tried resetting the tbeam but, at present, the only way I could re-connect was to delete the App and re-install.
I think it is actually stuck in the āConnectingā state, I have some nice mesh activity logging that is mostly done that I will try and get submitted tonight.
While I did resist adding a debug logging feature, the version with mesh logging has been submitted to app review, should make it a lot easier to track down the remaining strange connection / subscription behaviors.
Build with logging was approved for TestFlight, you should be able to see all the mesh activity now
I have been having issues with sleep mode and believe it may be a firmware issue with 1.2.45. @garth I created a bug report on git-hub for this. I have this issue with my android devices. When I restart the LoRa device, the issue goes away for several hours and then repeats. Makes managing remote boards hard.
Although it could still be an app issue.
Hi @garth - thanks, I have enabled the logging. There is now a lot of data there. Where is the log file stored? I maybe able to cut and paste parts of it for you to see. From my tests yesterday even with sleep disabled the map does not update the tbeamsā new positions as I move them from my home base tbeam. I think the tbeamās arrow may work - I will try that today.
it is a text file stored in the default app documents directory, wherever that is. I tried to set up export of the file but failed on my first attempt, you can copy the individual log entries from the log view.
Apple are not very open re App iOS files I feel. The log file main entries by inital title are: BLE connecting to tbeam (and disconnecting), BLE FROMRADIO (nodeinfo saved for tbeam X), BLE did discover FROMNUM ((Notify) characteristic for Meshtastic by Meshtastic_tbeam X), BLE did discover FROMRADIO, BLE did discover TORADIO characteristic for Meshtastic by tbeam X, and BLE Service for Meshtastic by Meshtastic_tbeam X. The rate the log receives messages is more than one per second. Hope this helps!
I cannot see anything indicating issues but maybe the issues are derived from messages not appearing that should appear?
I did think I would see gps position messages. I will try a walk test next while logging.
Would love to give it a try.
The TestFlight link is here Join the Meshtastic beta - TestFlight - Apple you do need to be on iOS 15
Is preferred radio supposed to stay selected?