Cool. It all looks good. Ready for messaging 
Italy has been added.
A version with messaging was just approved by beta app review.
2 Likes
How does the ‘Primary’ channel relate to the Android app channels?
I have tried ‘Very low range (but slow)’ and ‘Short range (but fast)’ but no success with either.
Also tried setting the name to ‘Primary’ on the other node (connected to Android). That actually sets it to #Primary-X.
It uses the default primary broadcast channel and packets from the textmessage app, I have done zero testing with custom channel configurations.
1 Like
Working for me. I have a channel already set up and it seems primary just references whatever primary mesh you already have set on your nodes. Great app!
Right. Not sure how I can proceed. I only have the one Apple device.
I can’t seem to find a setting on the Android app. which is compatible.
OK. Got it working. I switched back to two Android devices, got those two working, then switched one to the Apple device and the new app. Great!
I’ll begin testing.
I did notice I couldn’t remove the connected device this time. Swiping left made the red part appear, and then it disappears before you can press it.
Here’s a video I made of using it with a Tbeam and a TTgo small? not sure what the actual model number is… both running 1.2.45
1 Like
Hi I have three tbeams on battery running 1.2.44, two others on usb power running 1.2.10 and my iPhone is on 1.23.
Messaging works well. If I connect my IPad (1.23) too then the message history does not agree with the IPhone. I notice that powered tbeams are much easier to reach when scanning. This is not related to the Node tab last heard time - even after I have connected and disconnected - it still shows hours. Really nice to have messaging. Will do some hiking this weekend to get more info.
The message history is definitely distinct to the iOS device it is on and I have not figured out how to manage sleeping T-beams yet. There should be some improvement in the last updated times though I have only tested that with devices on 1.2.44 and 1.2.45.
Thanks for the reply. One problem I have is that trying to understand the cause of something on these devices is not easy! But it seems that the only way I have to update last heard time is to forget the devices in the iOS menu - even switch the BT off and on. Then the times update.
Sleep is a complete mystery to me. I would just prefer screen goes off after x minutes as sole energy saver and to carry some spare batteries. Very much appreciate your work on this.
It seems to be working nicely for me. The only problem I have is that you can no longer disconnect from a device by swiping left and then pressing the red part. The red part appears but then disappears again immediately.
I can connect to another T-Beam though and that disconnects the current one.
It seems to handle power saving much better than the Android app (or perhaps it bypasses it/ disables it somehow - which is good!). I’m not having any of the problems that I usually have with Android whereby the T-Beam device falls asleep and there’s nothing you can do with it until you push a button on it.
Excellent!
I’m running two T-Beams on their own internal batteries now by the way. It seems that when the T-Beam goes to sleep, it disconnects from the app. And that can be seen in the Bluetooth screen.
You wait a moment or two in that screen and the T-Beam appears as an available device and then you connect to it and carry on messaging.
If nothing else, it’s intuitive. (Whereas the Android app seems to hold the Bluetooth connection, but then the T-Beam is actually asleep and you can’t do anything with it until you push a button on the device itself. It’s quite confusing and inconvenient to have to push the button).
It would be great if this app could automatically reconnect when one presses the send button on a message. IE when I press send on a message, if it’s not presently connected the app does the same thing I do when I click on the device in the list of available devices - and reconnects.
It’s really very good. Thank you!
Actually, it does seem to do exactly this!
So the power issue is really slick from a sending perspective. The only thing is that nothing is received once the Bluetooth has gone to sleep. (Until you send a message, then it wakes up and all of your incoming messages appear too).
Can the app periodically connect to the T-Beam to check for messages (in exactly the same way it does when I send a message)? That would be great.
Also, there are no delivery receipts on this app yet. They’re quite useful - particularly when range testing.
1.25.1 updates last heard and snr for both the node info and position apps, so so you should be seeing accurate last seen on the mesh times when connected now.
I timed this badly at first and it crashed hard a lot, but is pretty stable now, though it does take 2 seconds. I still have to add some messaging if it is unable to reconnect.
I want to add the reconnecting logic, but I also want to be careful of the App Store rules, I think I have isolated the errors when sleep happens vs an intentional user disconnect so hopefully that will be a good solution.
I have not sent or received a read receipt successfully so I probably need to read some docs.
2 Likes
The issue with the Bluetooth device swipe/ red icon/ disconnect has changed a little. (Or I have realised when it happens at least).
I can connect to a new device, swipe left, press the red icon and disconnect all day long in the Bluetooth screen. It works perfectly.
However, if go to the messages screen, click primary and send a message, then go back to the Bluetooth screen the functionality is now broken. Swiping left makes the red icon appear very briefly but it’s gone before you can press it.
This persists until I restart the app.
I hope this is useful. Thanks for a great app!
1 Like
Super helpful details, I think I found the issue and have pushed a new version to beta app review which takes 2-18 hours so far.
All of the detailed feedback has been really helpful for me, I am a software engineer but this is the first swift / swiftui code I have written so I am not great at debugging yet and details that isolate the problem better help a lot.
3 Likes
That’s great to hear. Breaking software is my speciality!
I’ll give it a test as soon as it appears.
Thanks again.
1 Like