Most recent activity
-
Completely agree. However, many systems have some minimum overhead and the granularity of includes varies. We are actively working on trying to get sensible widget support, but I think you'll agree it's not a particularly easy decision.
-
Thanks for the pointers guys. I just found jim-knobf myself a couple of minutes ago.
The issues with widget sets are:
1) You can't please all of the people all of the time. Thus selecting one widget set and it's associated API's is not on.
2) We certainly don't want to bloat the system by including large widget libraries of which only a fraction will be used.
3) We think people should be able to make their own.
Thus, we'll be using the graphic elements from things like Jim Knobf, and inserting the real-time update code from ThingStudio, which is minimal, into them. This facility will be available to anyone using ThingStudio, not just us. -
Yep. You've got it. I spent about 30 minutes with iDraw (£16) to make the dial, pasted into a ThingStudio screen, and inserted the helpers to animate it. I'm an SVG noob, but it took me about an hour in total. The code to drive it is two lines with ThingStudio. You can actually do it today on ThingStudio, but we don't support these as libraries, you have to paste in the code each time, that's what the new version will allow. I just pasted this into one of my screens on the current version http://www.thingstud.io/screens/MTmhk7LwiN58ijKZP, (you'll need to signup to access it), the second slider down will move the pointer.
http://thethingbox.io/ do an SD card with a preloaded node-red, node, and mosquitto, but so far I've not been able to persuade them to upgrade to Mosquitto 1.4, which supports websockets. :-( . I suppose I could go into competition, but I'd rather they just upgraded their build...
-
Gordon, as I said, I'd be the first to admit that our UI is not great at the moment, we been concentrating on the architectural aspects of ThingStudio so far. Certainly, UI's are hard, even when using a great service like (ahem) ThingStudio, there is still a lot of work to get a really good UI. Reading this thread inspired me though, and I've started work on the widget system, so here is a teaser image of yesterday's prototype of an SVG widget made in ThingStudio. We'll be providing a set of widgets, but unlike everyone else, you'll also be able to make your own, and we hope the community will take up the challenge. It's still rough, but you can see where we are going. We will also shortly have a new, really spiffy UI for the actual IDE as well.
-
I don't think that we'll be doing MQTT hosting. It's really a core part of what we do not to see your data. However, you have the following options I know about:
-CloudMQTT have a free tier. If you use it, remember that they only support secure websockets, so select that in our 'connection' properties.
-If you are using a Mac, we have created a desktop app that has an MQTT broker included, as well as a serial <-> MQTT bridge for using ThingStudio with plain 'old Arduino's. http://blog.thingstud.io/recipes/how-to-use-a-plain-ol-arduino-with-thingstudio/
-I've also written a blog post about setting up a Raspberry Pi with the latest Mosquitto + Node Red. This is a really sweet combo. http://blog.thingstud.io/recipes/how-to-make-your-raspberry-pi-the-ultimate-iot-hub/
On windows, Mosquitto supply a pre-built binary.
You can also try the open server at http://test.mosquitto.org/All of which pretty much explains why we are not providing MQTT :-)
Blog posts on : blog.thingstud.io
Mike
-
I'm really comparing us to other approaches to IoT platforms where your MQTT (or other transport) traffic is sent up to a cloud service, which you can then access via API to get plots or stored data or whatever. All we do is serve up UI's and don't have any access to any of your actual IoT data. As far as encryption between the ThingStudio webapp and the broker, we support secure websockets (TLS), so that data can be protected. If you want to keep data safe and your devices don't have the resource to do encryption, then the advantage of our approach is that you can have your MQTT data going over a private network, just so long as it provides a outgoing gateway so you can access the ThingStudio servers for the webapp.
The attached diagram is probably easier to understand
-
I'm Mike from ThingStudio, and I'd just thought I'd weigh in with our view of how to do IoT UI's
-We've opted for MQTT as a first transport (which is already in place, btw), as it seems to have the most traction and the correct symantics for IoT.
-This also means that we aren't in the business of creating special libraries for every platform out there.
-We also decided on JSON payloads for MQTT, as this gives us the ability to send and recieve objects in a single message, and display them simply in the UI.
-We also opted for HMTL5 as the best fully cross-platform UI tool. Mobile is really, really important, but I also need to be able to make 'Mission Control'.
-Being able to share and publish apps is important. We do that to some extent already, but we will have fully shareable webapps shortly.
-Unlike, say, freeboard, we can work with or without an intermediate logic layer, such as node red.
-We are currenly deficient in pre-styled widgets, and we are working hard on that. However, you can already create ANY widget of your own with just some simple HTML. We believe that while it should be easy for you to get up and running quickly with professional looking widgets, you should be able to create your own widgets, which is why we started there.
-We think you should be able to control and monitor multiple devices on one screen, or have many people view on device. This is inherent in MQTT, but just saying...
Security and privacy are important, so we don't, and can't see your data, that is run on a websocket between your MQTT broker and your browser.
That's about it, if you like what we say, go kick the tires, http://www.thingstud.io, we are still in Alpha, but working hard...
Mike
Founder, ThingStudio. http://www.thingstud.io