Android app to interface with API?

[fanno]

Hello

I have some experiance writing android apps.

Would there be any interest in a open source native android APP for NightDriverStrip (using the rest interface)

I know there is a web interface (assuming i read it tight).

My experiance has always been that a native app is way better than just a web page.

I have not tried it my esp32's still in order allong with some strips and such.

If theres no interest i would propearly just use the web interface. But if others are interested too i dont mind working on one.

[mggates39]

There is a web server built in to some of the versions. There is also a stand alone web site that talks on the rest API. An android app would be fun. I would love to chat with you about your thoughts on it.

Marshall

[fanno]

Awsome, I have no expriance working on android app in a colaborate, Tho i am sure it could be done.
Mainly i guess it would be about making a solid framework of some kind that could then be expanded on.

As i am still waiting for my esp32's I don't have much of a grasp on what features there are to support.

But idealy it would need to provide a intuative interface that is easy and fast. (and i would expect need to support multiable instances at the same time.) (this would be the key advangate i think to the web all) it would be a 1-1 ration of page to instance.

Where a native android app could be made is such a way you can add multiable instances and send same command to each of them. (or an individual).

i think hardes part would be to make it intuative.

i am thinking some sort of method to "group" devices in a tree

Home

• Living room
  • TV
  • Dinner table
  • Sofa
• Kitchen
  • Window
  • Stove
    ...
    ...
    Idea beeing if you chose home it would send command to everything below to make lights match.

But in a way where you could commands could be raw commands or predefine series of commands/settings

eg Kitchen (predefined "spider man")
window = red
Stove = blue

eg Kitchen (red)
window = red
Stove = red

I am aware tha 1 esp32 could controll 2 strips/sections no probem. I am just thinking "modular"

[robertlipe]

Hi, Morten, and welcome. I'm reluctant to be a buzzkill as I well know that work gets done by someone wanting it done and doing it. We are, realistically, a small project. Be sure you look at that REST API and set your expectations appropriately. If you're familiar as a user with something like WLED, PixelBlaze, GoVee, or other tools that really expose a way to program effect and occupancy groups and more from little more than a remote, we just don't have that right now. I don't know if any of us have seriously gotten to a proposal and rejected the idea of device groups and pixel cluster effects; we just don't have it *now.* This isn't to say it couldn't be done and it's not to say that you and Marshall might not be able to extend the API in that direction. As one of my annoying bosses used to say, "it's a mere matter of programming." There are plenty of native apps in the industry that boss around strips via bluetooth (BanLanX, Stripco, Duoco, JACKYLED <https://github.com/kquinsland/JACKYLED-BLE-RGB-LED-Strip-controller#jackyled-ble-rgb-led-strip-controller>, etc.) Some of them have been reverse engineered or studied in ways that might help growing into that space, but hopefully staying out of copyright/patent space.

i think hardest part would be to make it intuitive.

This is the hardest part of UI-heavy development, by far, in any domain. As an example of the kind of thing you might need to develop just to implement what you've outlined, you'd really want your Android app (via BTLE? Radio?) to talk to one strip and have it boss the stove from the window or vice versa. You probably want those to stay tightly in sync. So you may now find yourself implementing strip-to-strip communications via ESP-Now <https://randomnerdtutorials.com/esp-now-two-way-communication-esp32/> (we have no such code now) just to get the strips building a P2P 2.4Ghz radio command brigade. Just making them all turn off and on in synchronicity is a bag of tricks of its own. Maybe that's a Home Automation/Alexa/Siri/Google-codename-of-the-quarter trick and maybe it's something we just learn to do for ourselves. I don't know - I'm just tossing it as an example of something you've casually mentioned that seems like it should be simple, but isn't and needs infrastructure. Challenging infrastructure. IMO, there's a lot of exciting stuff that can be done in this space, but it's not a matter of "just" needing client apps for even some of the things you've already described. There's work to do in the C++ code to make these happen. There is a small number of people that can/will try to help with such things (raises hand, pensively...) so don't expect that you're going to have an army of native coders available to convert an RFC into code. Of course, if you do it in something like Flutter that makes a WebASM or iOS app a natural fast-follow, you also now need to introduce compatibility windows where iOS app version X runs on ESP-32 code {X-Y, Y+Z} and offer some kind of carrot/stick motivation to keep everyone on at least bug-compatible versions of client and server code. That'll be new to us, I think. Wince the WebServer code ships inside our ESP-32 firmware image, they're always in sync. Don't let me discourage you too much. Please DO dig into the project, the current REST <https://github.com/PlummersSoftwareLLC/NightDriverStrip/blob/main/REST_API.md> API, and how you can best work with the current web app and existing API in a way to catch up for feature completeness and then figure out how to grow that REST API into the kinds of spaces you're discussing. It's an interesting possibility to decouple the REST API from the inbuilt web server. At first blush, that seems like something we should be able to do, but I don't know of any project that's done it. Sure, you COULD build, oh, a WebASM remote control app that ran on YOUR computer and spoke to the REST API over sockets/websockets that did interesting things. It sure seems like something we could do, but I don't know of anyone that HAS done it. (That doesn't mean it hasn't been done...) The REST API is more powerful than you could do over the IR RMT API, but it's still far from most of the list in, say, https://kno.wled.ge/interfaces/blynk/ (HTTP, Remote, JSON, MQTT, Serial, UDP, WebSocket, etc.) I'd welcome someone coming in and trying to do interesting things here and will try to help as I can. I'm just bracing you that the underlying APIs may not be on par to what you're expecting and may need some work. I'll try to help as much as I can on the C++ side of the ESP-32 ecosystem, but I can't promise huge amounts of help or influence. Good luck! RJL

…

On Sat, Dec 16, 2023 at 2:31 AM Morten Hundevad ***@***.***> wrote: Awsome, I have no expriance working on android app in a colaborate, Tho i am sure it could be done. Mainly i guess it would be about making a solid framework of some kind that could then be expanded on. *As i am still waiting for my esp32's I don't have much of a grasp on what features there are to support.* But idealy it would need to provide a intuative interface that is easy and fast. (and i would expect need to support multiable instances at the same time.) (this would be the key advangate i think to the web all) it would be a 1-1 ration of page to instance. Where a native android app could be made is such a way you can add multiable instances and send same command to each of them. (or an individual). i think hardes part would be to make it intuative. i am thinking some sort of method to "group" devices in a tree Home - Living room - TV - Dinner table - Sofa - Kitchen - Window - Stove ... ... Idea beeing if you chose home it would send command to everything below to make lights match. But in a way where you could commands could be raw commands or predefine series of commands/settings eg Kitchen (predefined "spider man") window = red Stove = blue eg Kitchen (red) window = red Stove = red I am aware tha 1 esp32 could controll 2 strips/sections no probem. I am just thinking "modular" — Reply to this email directly, view it on GitHub <#568 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD32BAWZU5WOGBDAMC6TYJVL53AVCNFSM6AAAAABAW3ARASVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TQNRZHEYDE> . You are receiving this because you are subscribed to this thread.Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/568/comments/7869902 @github.com>

[rbergen]

@fanno If you and/or others want to develop an Android app that interacts with the API that NightDriverStrip offers then you're of course free to do so. There's a couple of things to consider:

• Basically what @robertlipe said concerning where we stand and what reasonable expectations are. It won't be difficult to come up with ideas that are just not (yet) supported by the API that's available.
• The Android app being an app that's external to the software running on the ESP32s, we'd have to make it a sister project/repo akin to NightDriverServer, NightDriverUnity and the - I expect soon to be public - NightDriverDesktop. I'd be happy to create an empty NightDriverAndroid (or something similar) repo under the PlummersSoftwareLLC GitHub organization for the purpose, or alternatively accept a transfer of an existing NightDriver Android app repository if and when it's available.

[fanno]

Thanks for all your inputs so far @rbergen and @robertlipe

I am aware as i said i have not play with the api yet, that shall come soon enugh =)

It's posible i have compleatly miss understoond what the pourpose of the rest api is.
I have looked throw it before suggesting this "app" it seems from the names to have "a lot" of
features but ofcause not having tried it i dont know how complete it is. If it is missing a lot of stuff
then that ofcause is something that would need to work hand in hand with app creating.
if stuff is missing both the API and the app would be improved.

the only thing i have not "seen" in the API, is some kind of "auth", if one is woried about security. on the local network.

pehaps i am just "bad" at explaing , english not my first language and i am dyslectic.

Initially i was not thinking blue tooth. i was thinking via wifi.

the whole "grouping" of thins and such i did not intent to come off as beeing "in the cloud"

I will try to pehaps explain again i think pehaps i was missunderstood.

a single esp32 would controll what ever it would be.

"foler structure" (this folder structure could be shared with household members and what not via BT or what not.)
I imagen the controll require wifi conection.
Home

• area1
  • esp1
  • esp2
• area2
  • esp3
  • esp4

The grouping and the added esp's would be managed on the phone.
so you could do: ()
home = red
area 1 = blue
esp 4 = white

or what ever efect you wanted. they would be send to the indiviual servers on each esp.

I guess another way to say it is that the phone would act as "server" when you send a command.

But again i have not had a esp32 in my hands yet. so its posible i do not have the knowledge needed to understand what you said.

But in all fairness i am aware i am SUPER GREEN and new.

As to "NightDriverAndroid" it seems a little over kill at this point in time. A prof of consept would be need first atleat. unless just wanna "secure the name"

I have not made a repo yet, i was planing to make a quick and dirty showcase. When i get my hardware sometime after new year. i could propelfly start but not show off "working cases" untill hardware is wired up. (if there was any kind of interest, it seems like there are "some" at least. but this is till a new post. and i am in no rush)

but as to NightDriverStrip it self. if i/we were to get a app working prototype and there are api changes "need" i would have no problem pehaps looking at the my self as well maping pull requests and what not. i am a "noob" when it comes to c++ but i have made some stuff for my self. But i propearly not do this the "right" way as how "industri" do things.

[mggates39]

@fanno What type of application framework were you thinking? Kotlin or Java? Traditional, Compose or something else entirely?

[fanno]

@mggates39 The only thing i have experiance with is java. Granded it has been a year or so since i made an app.

But if there is a "consensus" for something else then that could be a thing.