Page 3 of 4 FirstFirst 1234 LastLast
Results 41 to 60 of 70
Like Tree70Likes
  1. #41  
    I think that is a bug with the mediaserver and bluetooth. I've noticed it too, when connected to my car headunit. I've found that the combo that works the most often is to click "previous track" a couple of times. Once usually does nothing and twice goes to and starts playing the previous track. Then I can press "next track" to get back to where I should have been.
    Did you know:

    webOS ran on a Treo 800 during initial development.
    Nafetz likes this.
  2. #42  
    I have an experimental build of My Watch, that is independent of mWatch, including its own package id. This will one-day allow you to run MyWatch and mWatch side-by-side. What I've done so far:

    • Confirmed with MetaView that he's cool with me hacking at his code-base and re-releasing under an MIT license (all attribution remains intact.
    • Modified the .patch file to notify my AppId
    • Finished factoring the Bluetooth comms and Pebble features into separate models
    • Re-arranged the connect and communication calls with the watch to be pseudo-deterministic -- something like a call-stack now exists
    • Modified the connection error handling to fail the connection less often
    • Implemented some crude re-try logic, including some basic "self-healing", if the message can't get to the watch within 30ish seconds
    • Re-factored the Dashboard as a user-facing notifier scene. Detailed logs are still in the app (behind a twisty)
    • Re-factored the launch behavior so the notification life-cycle is primarily shown using the Dashboard (a brief full-screen "loading" scene is necessary because of how the .patch works)
    • After a successful notification, the app completely shuts down (if it wasn't open already)

    What I have left to do:
    • Back out the music stuff (it doesn't work, and it will have to be a future project to re-write it. You'll have to stick with mWatch if Music works for you!)
    • Back out the timeout stuff. I suspect this was in place for those that want to leave the app running. In the new launch approach, the app quickly establishes a connection when there's a notification, then goes away. This is better for battery life, and also more resilient.
    • Continue improving re-try and error handling logic, possibly including a message queue
    • Test with the Pebble Time I'm getting for Christmas
    • Figure out how to package patch files properly, and make them work with Tweaks (currently preventing simultaneous use of mWatch and My Watch)

    If you want to try out this version, first install the patch:
    https://raw.githubusercontent.com/co...-mywatch.patch
    Then install the IPK:
    https://github.com/codepoet80/webos-...ee/master/_bin
    Last edited by jonwise80; 12/24/2018 at 03:01 PM.
    Nafetz likes this.
  3. #43  
    Help Needed

    I've tracked down the number 1 cause of failed connections to the watch.
    It exhibits as an error code 263, which is only sometimes fatal. Often, its safe to ignore the error and continue with the Bluetooth SPP connection -- this cuts failures by about half. The remaining 50% of the time, there's an underlying error from a lower-level Mojo service, BluetoothSPPAssistant, saying that the device /dev/spp_rx_25 does not exist.

    Looking in novaterm, its looks like this is the result of an incomplete clean-up: /dev/spp_tx_25 exists, but rx does not.
    If you delete /dev/spp_rx_25 from the command line, and restart the app, both files are created, and everything works again.*

    I can see two potential fixes:
    1) Figure out what's going wrong with the clean-up, and do it right (assuming I/MetaView were doing something wrong to begin with)
    2) Figure out how to execute a file command on start-up/error and delete the left-over file myself as part of the app (assuming its possible to access the file system from a Mojo app)

    Anyone got any suggestions?

    * Upon closer examination (these are loafers) it seems this is the result of an incomplete opening -- not closing, of the connection. I have a cludgy work around where I use Jason's FileMgr service to delete the files, then re-launch the app and try again. It would still be better not to get into this state...
    Last edited by jonwise80; 12/24/2018 at 12:42 PM.
    Nafetz likes this.
  4. #44  
    Good find. That's what I would have recommended as a workaround. It's possible that you may be dealing with a webOS bug, not necessarily an mwatch service bug. BT serial was added later in webOS' lifetime.
    jonwise80 and Nafetz like this.
  5. #45  
    Got my Pebble Time this Christmas morning! Its beautiful!
    On the plus side, connections from My Watch to the Pebble Time seem to be a lot more reliable.
    On the negative side, notifications don't actually make it to the watch. I'll be working on that while we're at the in-laws for the holidays -- good to have something to work on

    Quote Originally Posted by Grabber5.0 View Post
    It's possible that you may be dealing with a webOS bug, not necessarily an mwatch service bug
    I'm beginning to suspect you might be right...
    Nafetz and Grabber5.0 like this.
  6. #46  
    Quote Originally Posted by dkirker View Post
    I think that is a bug with the mediaserver and bluetooth. I've noticed it too, when connected to my car headunit.
    For me the bug occures with a wired headset (Bluetooth is off)


    Quote Originally Posted by jonwise80 View Post
    Figure out how to package patch files properly, and make them work with Tweaks (currently preventing simultaneous use of mWatch and My Watch)

    Hi,

    I was not so happy using Tweaks to switch MWatch functionality on and off. For me it was perfect to check if there is any Bluetooth device connected (instead of Tweaks) because my only Bluetooth devices are Pebble watches. Here an example of my Kodi Remote App:

    Code:
    var request = new Mojo.Service.Request('palm://com.palm.bluetooth/gap', {
    method: "gettrusteddevices",
    parameters: {},
    onSuccess: function(){
    Mojo.Log.error('ABOUT TO Report Title to ST-Watch MBW150');
    var request = new Mojo.Service.Request('palm://com.palm.applicationManager', {
    method: 'open',
    parameters: {
    id: "de.metaviewsoft.mwatch",
    params: {command: "INFO", info: transport.responseJSON[1].result.item.title + "\n " + transport.responseJSON[1].result.item.artist, appid: Mojo.Controller.appInfo.id}
    },
    onSuccess: function() {},
    onFailure: function() {}
    });
    }
    });
    This way MWatch is only starting when my Pebble is connected. If you are using several Bluetooth devices this is not perfect, of course. Maybe there is a way to check if the connected device has a name like "*Pebble*"?

    I'm looking forward testing your app in some days. Any chance to implement additional apps? I had a lot of fun the last months getting notifications from apps like Goooal 2, Amigo, Battery Monitor or JogStats with the suitable icons. Here's my patch for MWatch to deliver the right icons (it's in German so here's the Google Translation)
    jonwise80 likes this.
  7. #47  
    Quote Originally Posted by Nafetz View Post
    This way MWatch is only starting when my Pebble is connected. If you are using several Bluetooth devices this is not perfect, of course. Maybe there is a way to check if the connected device has a name like "*Pebble*"?
    Yes, this behavior is in my build. It starts up (with a brief "loading scene") then drops into a Dashboard-only scene while it tries to send a message. The "call stack" I rigged up, works like this:

    - Checks if the BT radio is on (if its not, it quits silently)
    - Checks if there's a trusted device that has "Pebble" in the name
    - Checks for the OS version
    - Tries to create a connection
    - Tries to create a SPP subscription
    - Tries to send a message, if it succeeds, it closes the dashboard scene after 8 seconds
    - If it fails, it re-tries up to 3 times, re-launching to create a new connection after 20 seconds each time
    - Finally, if it still can't get a message through, it leaves the Dashboard scene alive, but minimized with the error message (this may eventually go away -- once I'm done troubleshooting.)

    Much of this was there before, but because of the asynchronous nature of the calls in Javascript, it was basically a big race: connecting, subscribing and messaging all basically at the same time. This works if everything is ideal, but isn't very deterministic -- as in, you can't determine from the phone-side code if everything is working as expected or not.

    If I do issue my own patch, I'll have to make it independent of Tweaks. It would be possible for any app to send a message to My Watch for delivery, but they'd have to be written (or patched) to do so. I know the new Project Macaw developer is active on here, so maybe once my stuff is in better shape, I'll ping him about an integration. I will add your icon support to MyWatch -- thanks for sharing!

    Quote Originally Posted by jonwise80 View Post
    On the negative side, notifications don't actually make it to the (Pebble 4.0) watch.
    This is fixed. I was looking forward to debugging serial messages, but it turned out to be a one-line bug that took seconds to fix. Once done, it "just worked." I've re-built the .ipk and updated GitHub.
    Preemptive and Nafetz like this.
  8. #48  
    Quote Originally Posted by Nafetz View Post
    Here's my patch for MWatch to deliver the right icons
    These have been integrated into My Watch. I've made extensive improvements to the app preferences loading mechanism, which allows adding app support by modifying only a single line of the code. In contrast, you had to patch multiple sections of the original app, now you just add a row. In the future, I might be able to make this extensible without patching, through an external file.
    As a part of this improvement, the "options" section is now loaded dynamically based on the list -- removing the need for controlling notifications through the Tweaks app. A side-effect is that the list is now quite long. I should be able to filter the list by checking if a given app is actually installed, through further use of the FileMgr service app.
    mywatch_2018-28-12_161258.png

    Quote Originally Posted by Nafetz View Post
    For me it was perfect to check if there is any Bluetooth device connected (instead of Tweaks) because my only Bluetooth devices are Pebble watches
    I agree with this implementation, and have updated my .patch similarly. I'm now fairly confident in my patch file (by itself -- I haven't tested my .patch along-side the mWatch .patch).

    Also, I've restored some of the Music functionality (notification, not control.)
    Grabber5.0 and Nafetz like this.
  9. #49  
    icon48.png
    My Watch Release 1.0.3

    After going back-and-forth between using my own AppID and using the original, the final deciding factor was that existing apps already support the old AppID, and would have to be updated to support mine as well. Given that most of those developers are no longer active, this seems the route with the best chance of compatibility. As such, think of My Watch as a drop-in replacement for mWatch.

    You can use the original patch, found on Preware as "Bluetooth watch - SE MBW-150" or mine, found on GitHub, which does not depend on Tweaks. But you can only have one of the two apps installed at a time.

    With this release, the big list of supported apps is filtered by what is actually installed on your phone. Installed apps are scanned at each launch. This, and the Bluetooth connection repair function discussed above have introduced a dependency on FileMgr, which is available on Preware.

    I'll be submitting to Preware, but you can also pick up the compiled binary on GitHub:
    https://github.com/codepoet80/webos-...ee/master/_bin

    PS: Notification success rate on Pebble Time is near 100%.

    screenshot.png screenshot1.png
    Nafetz likes this.
  10. #50  
    Not sure if I'm doing something wrong or what. With My Watch open, the test and music notifications are working. Every time I close the app, my Pre3 immediately disconnects from my Pebble Time Steel. If I reopen it, it reconnects. Am I just being impatient, and not giving it time to reestablish the connection in the background? It was late and I went to bed after a bit.

    The UI changes look great by the way. I need to reload my prepaid sim so I can do more testing this weekend.
    jonwise80 and Nafetz like this.
  11. #51  
    Quote Originally Posted by Grabber5.0 View Post
    Every time I close the app, my Pre3 immediately disconnects from my Pebble Time Steel
    This is by-design. Originally, I wanted to re-factor the whole thing as a UI-less service. You'd only use a scene to set-up options -- more like the Pebble app on iOS and Android. Ultimately, that's not possible without a complete re-write and total break from compatibility with existing apps/patches; mWatch was designed around the app launch behavior.

    As a compromise, I ended up re-factoring it around momentary connections, with minimal UI. You start the app only to configure it, then you shut it down and the BT connection is closed (and cleaned-up.) When a notification comes in, the app will re-launch -- you'll see the default webOS splash screen, followed by a short-lived Card that tries to mimic it, only long enough to spawn the Dashboard scene at the bottom. The Card scene cleans itself up and the App assistant handles dispatching the notification to the phone, using the Dashboard to display progress or error information. If all goes well, the Dashboard scene closes itself as well and the BT connection is again closed. Since webOS doesn't have BTLE, this is the behavior that has the least impact on both the phone and the watch battery.
    It has a secondary advantage in that each notification is a fresh connection attempt -- a fresh slate. If something goes wrong on the previous attempt (like you don't happen to be near your phone) the app won't get stuck, it'll try again next time from the beginning.

    During Music playback, you may want to leave the app -- and the BT connection -- open. I'm still experimenting with this myself. In that case, launch the app, but do not swipe the card away. The next notification will notice that the app was already open and will not try to close it or dispose the BT connection when its done.

    Quote Originally Posted by Grabber5.0 View Post
    I need to reload my prepaid sim so I can do more testing this weekend.
    That'd be awesome, I appreciate the help with testing! Its hard to see the advantage of the new behavior without an externally triggered notification (like a text message -- I've sent myself a couple hundred over the past few weeks!) When things work as planned, My Watch is practically invisible, and the notification sometimes makes it to the watch faster than the built-in webOS apps can get their own dashboards or notifications launched.
    Its more than a little weird when my watch starts buzzing with a phone call before the phone app launches on my phone!
    Last edited by jonwise80; 12/29/2018 at 09:27 AM.
    Nafetz likes this.
  12. #52  
    I tested again this morning, and I see it re-established the connection when it needed to send a notification to the watch. It doesn't log anything to the system log during the time it's not connected, so I can't tell if it's trying periodically, but it did kill the battery in the Pre3 overnight while the phone was in airplane mode. Though if the app is entirely notification driven, that doesn't make sense does it?
    Last edited by Grabber5.0; 12/29/2018 at 10:11 AM.
    Nafetz likes this.
  13. #53  
    Quote Originally Posted by jonwise80 View Post

    When things work as planned, My Watch is practically invisible, and the notification sometimes makes it to the watch faster than the built-in webOS apps can get their own dashboards or notifications launched.
    Its more than a little weird when my watch starts buzzing with a phone call before the phone app launches on my phone!
    That happens often on Android too. I frequently see notifications on my watch before my phone lights up. Kinda gives an idea of the order of things in the background.
    Nafetz likes this.
  14. #54  
    Quote Originally Posted by Grabber5.0 View Post
    Though if the app is entirely notification driven, that doesn't make sense does it?
    No that is strange. Currently, if there's a failure, it will keep the Dashboard stage open -- which makes it easier for me to troubleshoot. Otherwise, the last instruction is "closeAllStages()" which I believe should completely shut-down the app. It also goes to that same clean-up code if it launches and finds the Bluetooth radio is off (Airplane mode). If its not logging anything, I assume that means its not doing anything. But maybe there's something about the app lifecycle I don't know?

    Do you have any way of knowing for sure that its My Watch draining the battery? I haven't seen that myself, but then I use the phone as a daily driver, so don't expect the battery to last more than 24-36 hours normally.
    Nafetz likes this.
  15. #55  
    Quote Originally Posted by jonwise80 View Post
    No that is strange. Currently, if there's a failure, it will keep the Dashboard stage open -- which makes it easier for me to troubleshoot. Otherwise, the last instruction is "closeAllStages()" which I believe should completely shut-down the app. It also goes to that same clean-up code if it launches and finds the Bluetooth radio is off (Airplane mode). If its not logging anything, I assume that means its not doing anything. But maybe there's something about the app lifecycle I don't know?
    I think you have a pretty good handle on it. There are some quirks with logging though, as on-device not much gets logged by default, so critical stuff I log at error level whether it's an error or not. There is a framework_config.json that has a setting in it for logging that affects how much gets logged, to the point where even high priority stuff can be disabled. I do like that the app has its own log window so I don't have to look in the system logs for everything, but it isn't clear whether it shows everything or only some things. It looked very similar to what I saw in Lumberjack.
    Quote Originally Posted by jonwise80 View Post
    Do you have any way of knowing for sure that its My Watch draining the battery? I haven't seen that myself, but then I use the phone as a daily driver, so don't expect the battery to last more than 24-36 hours normally.
    I haven't seen anything yet, but I just plugged the phone into my laptop so I can shell in and try to get some more info from the logs. Since it was in airplane mode, and I didn't get any calendar reminders, nothing should have triggered the app. Unfortunately, since the battery died, I have no way of knowing whether the app was open at the time or not.
    Edit: holy crap! The activity manager is going crazy! I am not positive, but it appears it could be related to the contact linker, as there are occasional contact linker messages interspersed in the logs. Then again, correlation is not causation right? LOL
    Last edited by Grabber5.0; 12/29/2018 at 03:48 PM.
    Nafetz likes this.
  16. #56  
    It was definitely the contact linker.. it stopped after I manually purged my contacts using Impostah. I had disabled contacts for Google and Hotmail, but my Hotmail contacts were not being removed. I just re-enabled Google contacts, and I'm waiting for it to finish "linking" them with nothing to re-establish the "Person" objects. Based on that, I'm thinking it may be safe to rule out My Watch, but I'll decide for sure later. It is definitely charging faster via PC USB now that the linker isn't going insane. Edit: seems to be fixed now.
    Last edited by Grabber5.0; 12/29/2018 at 07:42 PM.
    jonwise80 and Nafetz like this.
  17. #57  
    Quote Originally Posted by jonwise80 View Post
    During Music playback, you may want to leave the app -- and the BT connection -- open. I'm still experimenting with this myself. In that case, launch the app, but do not swipe the card away. The next notification will notice that the app was already open and will not try to close it or dispose the BT connection when its done.
    After a little experimenting, this is not ideal. If I leave it open, every time the track changes, the My Watch card comes back into focus and stays. If it's not open, it at least goes away when it's done and leaves you in the app you were in. This is something I can't remember about no-stage apps - whether you can launch it without a stage and only create the stage and card if the card needs to persist. I can't remember if I ever did any experimenting with this or not..
    Nafetz likes this.
  18. #58  
    Quote Originally Posted by Grabber5.0 View Post
    If I leave it open, every time the track changes, the My Watch card comes back into focus and stays
    I think I should be able to fix that pretty easily in the next build.

    Update: tested fixed on 1.0.4, on GitHub

    I also did a little investigation into 2 missing features in MyWatch...

    - Stop notifying the watch if a call is answered: I found this in a version of the .patch file that does not work on my phone. I don't know if maybe the phone app changed since the patch was made, but I can't deploy the patch (it errors out, and testing proved it to be the section that patches the "phone answer" activity in webOS that causes the .patch not to deploy) so I can't finish re-working this feature. As currently implemented, the watch just buzzes for 10 seconds. If someone can help me update/fix the .patch I should be able to re-implement this.

    - Control music from the watch: It appears this was a breaking change in the Pebble firmware, and although I paged through the GadgetBridge stuff, I don't think I have any hope of restoring this functionality. Although much of the Pebble documentation is still online, I couldn't find any for the Music watchapp.

    At this point, my next move will be to back out the persistent troubleshooting Dashboard (since removing it will improve recovery rate on bad connections) and clean-up the logging levels, as an alternate. After that, I think I'll call this effort done... I still have an Enyo project I want to start before my phone turns into a pumpkin.
    Last edited by jonwise80; 12/30/2018 at 08:21 PM.
    Grabber5.0 and Nafetz like this.
  19. #59  
    Hi,

    couldn't wait to get the My Watch App, because I was not at home the last days and couldn't participate in testing and discussing
    What I saw so far is really great work! Thanks for that!

    Quote Originally Posted by jonwise80 View Post
    If all goes well, the Dashboard scene closes itself as well and the BT connection is again closed. Since webOS doesn't have BTLE, this is the behavior that has the least impact on both the phone and the watch battery.
    I'm not sure about bluetooth and battery life. There was an article in the help sites of pebble that it's better for battery lifetime (of the watch) to keep the connection established. But I don't know if it's the same for phone battery life.
    As a side effect you have an alert every time you move away too far from your phone. Depending on your watchface you might notice you lost your phone about one minute after you really lost it.
    So maybe it's just right the way you developed your app: You can chose personally if you like to have My Watch disappearing or not. I was using my Pebble a lot in the last months and the times I had to look on my Veer have strongly decreased. So I personally would prefer having My Watch open all the time and see a green sign that everything is still connected - and that's possible at the moment

    Would it be better to have the logging part in bigger font size? For me it's hard to read. I had a
    Code:
    <div id="log-output" style="font-size:22px !important;">
    in my MWatch-patch. But thats a matter of personal taste, too.

    I'm very motivated again having a look at the music issue. I hope I can spend some time for this the next days
    MudShark22 and jonwise80 like this.
  20. #60  
    Quote Originally Posted by Nafetz View Post
    There was an article in the help sites of pebble that it's better for battery lifetime (of the watch) to keep the connection established.
    For BTLE, it definitely makes sense to keep the connection open. For our flaky Bluetooth, the problem is that if you walk away from your phone, and it disconnects, it will never re-connect unless you quit the app and restart it! An intermittent connection increases the chance of recovery by 100 times. If you know your phone and watch will stay close, you can leave the main scene of the app running, and it will keep the connection open. (I fixed the issue where the app always grabs focus!)

    Quote Originally Posted by Nafetz View Post
    You can chose personally if you like to have My Watch disappearing or not.
    Quote Originally Posted by Nafetz View Post
    Would it be better to have the logging part in bigger font size? For me it's hard to read
    Quote Originally Posted by Grabber5.0 View Post
    I haven't seen anything yet, but I just plugged the phone into my laptop so I can shell in and try to get some more info from the logs
    I've added a trio of features for you fellow developers. They're all in a new "Troubleshooting" app menu, in the 1.0.5 build (available on GitHub):
    • Persistent Dashboard means the app does not close the Dashboard stage after a notification launch.
    • Large Log Font changes the log area to use 18px (22px seemed way too big!)
    • Verbose Logs means that all messages sent through the UI logger will be elevated to Error level

    Of course, you can always set the log level through the SDK command line:
    palm-log --system-log-level info
    I've added a little more nuance to the log levels, where you probably only need to look at the ones that default to ERROR to troubleshoot, but if you want to see everything, go ahead! The log panel is now a scroller, so it doesn't chop off older messages -- however, be aware that because the whole app is about launching and re-launching, messages in that window will frequently be purged! The SDK tools are still the best way to see what's going on throughout the life cycle.
    mwatch_2018-31-12_133641.png

    Barring any major bugs, I'm going to move on to other projects. If you want to contribute, it would be great if you could do so against the GitHub project, instead of patches or forks. I've checked with MetaView, and his position is the same as mine: this is open -- feel free to make it better!
    Last edited by jonwise80; 12/31/2018 at 04:52 PM.
    Grabber5.0 and Nafetz like this.
Page 3 of 4 FirstFirst 1234 LastLast

Similar Threads

  1. Replies: 27
    Last Post: 03/01/2015, 08:37 PM
  2. Pebble + HP Pre 3
    By blaziiken311 in forum HP Pre 3
    Replies: 13
    Last Post: 08/22/2013, 12:48 PM
  3. Smartwatch: i´mWatch. Video.
    By akitayo in forum Other OS's and Devices
    Replies: 14
    Last Post: 09/09/2012, 12:43 AM
  4. Should HP keep the pebble look?
    By nimer55 in forum General News & Discussion
    Replies: 32
    Last Post: 02/23/2011, 09:17 PM

Posting Permissions