Communicate with Particle Devices using MIT App Inventor 2


#21

@Rhino: if you change the “ProjectBucket” property of the FirebaseDB1 component to a top level tag, you can then access the next lower level tags directly. So you can make the ProjectBucket property “LivingRoom” (either in the designer window or programatically in the blocks view). Then, inside the “when FirebaseDB1.DataChanged” event handler, “call FirebaseDB1.GetValue” for each tag that you want to read. Inside the “when FirebaseDB1.GotValue” event handler, you can test which tag got read and read out the value directly. Alternatively, leave ProjectBucket to the database name (default) and access lower level tags directly using a path-like construct, i.e. “LivingRoom/Light” and “LivingRoom/TimeStamp”. Either way, you let Firebase parse the JSON tree rather than you doing it in AI2.

The only issue that I am having is that when I read out the TimeStamp this way, the string in AI2 terminates at the colon (:). I think that this is a bug in the AI2 Firebase component code - perhaps it interprets the colon as a tag:value separator rather than just part of the double quoted string. I need to do some more playing around with this, but the ultimate workaround would be to not use the webhook-supplied timestamp but include a Particle device firmware timestamp in the published string, formatted however I choose to do so (thus ignoring colons if they make AI2 unhappy).


#22

@BobG
Thanks for that information. That does seems easier to manage. I’m on the road this week for work, but if I get some time in the hotel I’ll check it out. I’m sure the family won’t mind me randomly turning lights on/off. :smile:


#23

@rhino: I have implemented a solution based upon the work of @rickkas7 and yourself. It works, but I have found the notifications to be unreliable. I have a simple test that processes a button push input to a Photon which publishes an event to the Particle cloud. A webhook picks up the event and PUTs the default webhook data (cloudID, event, data, timestamp) to a Firebase DB. This part all works perfectly, all of the time. But the MIT App Inventor 2 .DataChanged event may or may not trigger when the app is closed. I seems that the app is still running when closed but when the Android OS needs resources (or perhaps just feels like it), the OS stops the app from running in the background. Researching how to make the app always stay alive and run in the background has so far yielded a number of statements that MIT App Inventor does not support this (that it is not possible).

The Pura Vida “Simple Notification Extension” has a “.MoveTaskToBack” method. I tied this to “when BackButton.pressed” because without this statement, the app always stops if you terminate it with the back button (whereas the home button leaves the app running in background, but only until Android decides otherwise). This quick fix worked for the back button issue, however even when I exit out of the app this way, I find that if I do a lot of stuff on my phone (web browsing, viewing pictures etc.) for even a few minutes, then the app is gone from background and the notification does not work (because without the app, the .DataChanged event handler isn’t running).

I thought that I’d pass this along for you and others who might be considering this solution. I will continue to write it up and publish it, but I don’t recommend it if you are relying upon the notifications coming through. At least this will be unreliable until the MIT team provides a way to actually make the app run in the background and keep the OS from stopping it.

I don’t have an alternative solution. Perhaps have Twillo send an e-mail (but this costs money and does not provide a way to open the app from the notification nor to send data to the app, albeit the data can still be published to Firebase and then available if you manually open the app). Any other suggestions about this would be appreciated.


#24

I’ve been waiting to create a post about Thunkable, which is, I believe, a spinoff of the MIT App Inventor initiative. I have successfully created 2 apps to use as smartphone interfaces to my Particle products. The first one merely makes calls to published functions in order to “control” the associated Particle device. The second app makes calls to to published variables in order to read temperatures and equipment status information. There’s no need to separate these functions–it’s just what I needed in each of these unrelated apps for now.

The development environment (for iOS) is still pretty new and evolving and the documentation is a bit light at this time. However, I have been able to create two effective iPhone apps without having to go the traditional route which would likely have required too much effort on my part. The Android tool looks to be far more polished and functional. The newest development promises one environment for developing an app that can be distributed to both iOS and Android.

I have not yet published my apps to the Apple App Store, so I can’t relate any issues associated with that critical step. However, Thunkable provides a mechanism to allow live testing and then single downloads of apps for more exhaustive testing.

I had been using bubble.io to create web apps, but have found the Thunkable app to be far more responsive based upon my limited development and testing.

In any case, this seemed like the ideal place to reference what I’ve learned this week. I find this development to be very exciting and a real enabling technology!


#25

@ctmorrison: yes, Thunkable is an MIT App Inventor distribution (there are several of these, they are completely legal). It used to be just a clone of MIT App Inventor, but then they redesigned the IDE and released an iOS version on their new IDE. They also have something called Thunkable/x in beta which is supposed to be cross platform development, but you need a beta license to try it out and there are a lot of components for it that have yet to be developed. In the meantime, MIT is working on an iOS version that should (in theory) support cross platform app development. It is supposed to be available this year.

My co-developer, Jim, has signed up for the beta license to test out Thunkable/x, but we have no results yet. And we are trying to follow the MIT progress as best we can. One clear issue is whether any cross platform IDE can support App Inventor extensions, since the extensions (today, at least) are developed in Java (the MIT team is re-designing each App Inventor component is Swift, for the iOS version). We have needed the TaiFunTools extension to do base64 encoding in order to log in to Particle using login/PW, and more recently, we have used the Taifun Simple Notification Extension to provide notifications on a Particle.publish(), albeit there are issues with using this approach (this tread has been mostly about these issues).

You might be interested in work that we have done (for Android only, so far) that is similar to yours:

You also might be interested in the template that we have created:

This template avoids the need to hard code the Particle user access_token and deviceID into your app. It provides a second screen where you can log in to your Particle account, obtain a list of your devices, and select a device to use for your app session. The credentials are stored in a TinyDB component that persists across screens and app sessions. So each time that you open the app, it will ping the last selected device for you and also allow you to change devices at any time. Sadly, the aforementioned extension is necessary for this template and it may (most likely isn’t) compatible with Thunkable iOS (but perhaps someone has ported it over, I don’t know).


#26

@BobG, thanks for the feedback! I’m strongly encamped in iOS at this point in time due to my user base, but fully expect to roll into Android in the not-too-distant future. Having a tool that would “create” apps for both environments would be huge. It’s the reason I had settled in on bubble.io and may end up going back that route to avoid having multiple development environments for smartphones.

Thanks for sharing references to your developments. This forum is an amazing resource!


#27

I just tried out Thunkable upon your recommendation and absolutely love it! Thunkable X is now the main release and works perfectly on all of the devices i have tried. I am working to develop a simple app to control lights that are controlled with the Particle Photon board, and am curious if you would be able to share your Thunkable project where you were able to control your particle with me and the community? It would be a massive help with my project, as I am still having some issues getting the particle board to communicate with my app through Thunkable.

Thanks!


#28

Hi @SpaceCadetsLights, I’d be happy to share one of the apps I’ve developed. I managed to get one of my apps (Relevant Remote) published on the Apple App Store and an earlier version on the Google Play store. Pretty cool that you can do this via the single development environment. Give me a bit to find one I can share that involves controlling my garage doors. It’s simple, but shows the basic concepts of communicating with the Particle devices (ie calling functions). With those basics, you’re set to do what you please!


#29

Thank you so much! I have spent most of the day today trying to make this work, any help is greatly appreciated.


#30

Is the app made with Thunkable X?


#31

Yes, it is a Thunkable X project. I’ve just shared it as a Public Project (via Thunkable) and assume the name stays the same at GarageDoors. Please let me know if you have trouble finding it and/or understanding what I’ve done. It is really a simple project, but does what I believe you’re attempting to do in principle. I have two Particle devices for my garage doors: 1) monitor open/close status and 2) act like a garage door button. I won’t bore you with the history of why 2 devices, but it involved the Bluz platform which didn’t pan out well for me. In any case, I’ll likely be redoing the control, reducing to 1 device for both reading door status and controlling the doors. All of that is pretty simple. This app only pertains to controlling the doors, not monitoring status.


#32

According to how I understand Thunkable’s docs, I believe this is the easiest way for you to get a copy of my project:
https://x.thunkable.com/projects/5d67d8548c5a334077731cad/project/properties/designer/

You should then use the Make Copy button to make a copy if you wish.


#33

I have been messing with your app. The problem i am facing is that I need to be able to have my users create a username and password that is sent to particle and registered using oauth. Then particle will return a token for them to use. But when the app sends their information to the particle api it has to be base 64 Encoded. I can not find a way to do this in Thunkable X. With the classic Thunkable there are extensions that do this, and I have a functional app running there, but this app needs to have cross platform support so I am trying my best to make Thunkable X Encode text to base64. Any help would be great! I am making no progress…


#34

When I first created the Particle App Template, I tried to think up a way to base 64 encode the username:password without resorting to an extension. Frankly, this is very difficult to do in AI2 because base 64 relies on gaining access to the underlying ASCII codes and then to do bit level manipulation on groups of these codes. AI2 doesn’t support either of these functions. The best idea that I could come up with is to load a subset of the ASCII table into an AI2 table to solve the problem of gaining access to the ASCII codes to begin with. Then, one can do the bit manipulation mathematically; e.g. left shift by multiplication (by powers of 2). All in all, this was so very ugly that I punted and used the base 64 encoding block that is part of the very wonderful Taifun Tools. Unfortunately, AI2 extensions (like the Taifun Tools) must be created in Java using Android Studio in the MIT development configuration. I don’t believe that Thunkable X has published a means to develop extensions for it and I also don’t believe that the upcoming MIT release with iOS support will have support for extensions either (at least, not initially). You can try the ugly approach above; I wish that I could come up with a better solution, but so far I haven’t.


#35

@SpaceCadetsLights, I did a quick search for a base 64 encoding service API, but didn’t find anything. If you have access to a web server where you could write your own code (API) and call it to do the encoding until another more elegant solution comes along, that might work for you. oath is kind of above my pay grade, so I guess I can’t help too much more.