Version 1.0 of IoT Buddy submitted to the App Store… I have no idea how long the approval process takes, or if they will accept it, but I’ll let you know. It’s pretty simple right now, but I’ll keep working on features.
Apparently it can take up to a week for an app to get reviewed…
@physicsnole, hmmm… let’s wait what will goes on…
I would love the contrary of my statement to be true!!!
My app just sends HTTP POST requests with user assigned values. You can read those values with something like the inputPort class, and perform whatever tasks you want with the imp. For example, using a button press, I could switch an Imp pin from HIGH to LOW for a second and drive a relay closed and then back open in order to trigger my garage door opener.
@ jwehr, I don’t say that app is wrong or so on…
I just say that we are looking for imp-to-imp or WiFi device-to-imp (and vice versa) communication. In spite of fast growing 3G/4G - Wifi router market, WiFi internet still is problem in rural area or is expensive.
I’m sure - imp development team know these issues very well…
@smartmaker We have tested HTML, and it works. The problem is that the interval to send data to the imp is limited, besides that, a native app is able to work in the background and requires less battery.
@PeterAP like @physicsnole stated, all communication with the IMP goes via the IMP cloud, this is also the way this app will operate
@ Teun, I know it:) Currently some WiFi LAN is necessary.
I’m talking that direct communication will be great, like using different WiFi shields for Arduino… or ZigBee… imp cloud definitely have advantages but in some occasions direct communication will be more effective. For example, I need to control about 15 impees in the same room (remotely controlled lab) or illumination control over 0,5-1 kilometre long street (17 to 35 impees).
I suppose - lets’s wait for direct communication possibility in such cases…
I think its a patent infringement issue. The method of local wireless control is already patented and electric imp cannot infringe. Their patent is for network control over internet. Hugo and others have stated many times this will never be achievable with an imp… I wish it weren’t so…but unfortunately it is
It’s not about patent infringement, it’s about what electric imp is attempting to do. Local wifi control products have been around for many years, we can’t bring much new to that arena…
@Hugo, Agree - it is possible to find some on the market (definitely not so much and not so many years) and not to easy them get to work:)
I’m just saying that it will be good to add local communication to imp. For some solutions. Local communication can help only a little for telecomands-telemetry purposes. Here the imp is the best, I have tested. But local communication can help to resend data from device to device in the same room:)
@physicsnole, “local wireless control” never was been patented - starting with Tesla radio controlled boat at the very end of 19th century till today. IEEE standards are open. Patented are some parts for some solutions, not WiFi at all.
Yes, I was referring to the method of using wi-fi for various purposes; ie. wireless sensor networks. Not the actual protocol. Sorry for the confusion.
How is the Status of IoT Buddy?
Wish I knew. All the other apps I have created were for my workplace or personal, so this is the first one I’ve actually submitted to the App Store. According to Apple they approve most apps within 7 days, and I just submitted it yesterday. Today when I was writing up more directions on the help page, I realized that I hadn’t changed the title on the Settings page. Ooops. I’ll probably resubmit it instead of waiting to see if they flag it.
I was wondering what you guys would allow as far as using the Electric Imp logo or name in apps or breakout boards. I didn’t want to step on any trademark or copyrights, so I didn’t reference Electric Imp at all. I would have loved to use the Imp logo in the App icon… Like an Imp holding an iPhone, or beaming binary data from its head to an iPhone. If I can or need to do something to be able to, let me know, or point me in the right direction. I am also working on designing and printing a PCB that uses the Imp and would like to know what the regs are on using the logo on the board silkscreen, assuming it was to be eventually sold as a kit or something of the like.
I’ll let you guys know the second the IoT buddy is available. Also check out the help page to see what it looks like, and give me ideas on new features. I’m already thinking of new ones myself.
I’m eager to see what Teun’s group comes up with.
@jwehr Special request: please add a slider.
I’ve been thinking about a slider, and how it would work. UISlider has a property called continuous, that you can turn on and off, meaning it either fires constantly while you change values or only when you release the control. I can’t imagine that setting it to continuous would work really well, so my initial thought would be to turn that off and only send a value at control release. Otherwise it would be constantly trying to send HTTPS requests as you changed values. That might be interesting to test.
My settings page is completely crammed full in the space that the keyboard doesn’t take up, so I need to rewrite that as well if I want more features.
I noticed a slider with a http request for every value change resulted in the agent/imp locking up. I would have to power cycle the imp. I had to change the slider to on release in order for it to work smoothly!
Good to know. I’m going to program it to only fire on release.
Ya something didn’t like 255 http requests in a second
I’ve got a slider in my app and had to set the UISlider to not update continuously for that same reason - you can set it in Interface Builder.