Control puck with a uwp app?

[espruino-discuss]

Posted at 2016-12-29 by user71773

If I want to send control commands such as LED1.set(); to the puck from my own uwp app, what format should I send it in? (string?, byte? etc.).

[espruino-discuss]

Posted at 2016-12-30 by dklinkman

I don't really know what a uwp app is (I'm stuck on Windows 7 everywhere). But if it connects to the puck via the UART service, you can probably just send strings. Terminate each line with a \n as if you were hitting enter after each line.

[espruino-discuss]

Posted at 2016-12-31 by user71773

Ok. The UART service is the gattcharacteristic with the ID 6E400002-B5A3-F393-E0A9-E50E24DCCA9E right? Do I need to do anything code-wise to the puck before it can receive input in this way?

[espruino-discuss]

Posted at 2016-12-31 by dklinkman

Not really. I can send code or commands via that characteristic just as if typing at the console. If you enable notifications on the TX characteristics you'll get responses too.

[espruino-discuss]

Posted at 2017-01-14 by user71773

ok, so I can connect to the puck, send code to the relevant characteristic & get a notify on change from the tx characteristic. That's all good. However, when I add my own services & characteristics to the puck through the Espruino web ide I cannot not find them through my app in the same way that I can find the original service (the "6E400001-etc."). Should I be able to or do added services not show up in the same way as the default one? Also can I check using the Espruino web ide what services are available on my puck just to check I have actually added them properly?

[espruino-discuss]

Posted at 2017-01-14 by dklinkman

The code I posted here works for me. Post

Essentially defining a service and characteristic on the puck which is what I think you are trying to do. The value from the characteristic can then be read using nRF Connect.

[gfwilliams]

Posted at 2017-01-16 by @gfwilliams

As @dklinkman says, it's best to check with the nRF connect app. You should be able to access them in the same way as you do the UART services

[espruino-discuss]

Posted at 2017-01-16 by user71773

I have added a service to my puck using the following code -

NRF.setServices({
  "6E400004-B5A3-F393-E0A9-E50E24DCCA9E" : {
    "6E400005-B5A3-F393-E0A9-E50E24DCCA9E" : {
      value : analogRead(D29),
      broadcast : true,
      readable : true
    }
  }
});

but I don't see it in the list of services when I use my app to connect to the puck I still only see-
0x1800, 0x1801 & 6e400001-.....

have I added the service wrong? do I need to activate the service every time I connect to the puck or something? Any thoughts would be appreciated.

[gfwilliams]

Posted at 2017-01-17 by @gfwilliams

It should be NRF.setService**s**({ (that code should have been producing an error when it runs).

Also, try leaving broadcast out - none of the examples I've posted use it and if I'm honest I'm not 100% sure what that really does Bluetooth-wise.

You shouldn't have to re-activate or anything though. Just set it and you're good to go.

However you can't update services reliable when you're connected - so make sure you have at least disconnected and reconnected before checking the services.

Finally, if you're on iPhone it seems iOS caches the available services so it's almost impossible to see an up to date list - it's probably better to use Android to check if you can.

[espruino-discuss]

Posted at 2017-01-17 by user71773

I did put an s at the end of services when I wrote the code in espruino, it was just miss-typed in my post so that's not the issue. Or are you saying I need to put ** either side of the s? The app I have written is for windows. UWP stands for universal windows platform. I can use the existing service & characteristics just fine with my app but can't find the ones I add myself. Any other ideas?

[gfwilliams]

Posted at 2017-01-18 by @gfwilliams

Or are you saying I need to put ** either side of the s?

No, just NRF.setServices

I'd try using the nRF connect app (ideally on Android as iOS has some cacheing issues) and checking that the app itself can see the services first. That way you can narrow down whether it's some issue with the UWP app or with how the Puck is set up.