Comments (4)
Since live commands are implemented on devices the ditto SDK (Java AND JavaScript, capital 'and' since I fear the latter is a bit under-developed feature wise 😅) needs to provide as much guidance / abstraction as possible to ease the agent implementation. Some initial thoughts on this:
- if a command is not yet implemented for a feature on the live channel a 400 with an "unimplemented" notice should be returned. 400, because I don't know if there's any better suited status. 406 sound similar, but is semantically different.
- implementing the commands needs an API to 'plug-in' implementations
- for AMQP and MQTT connected clients I suppose (at least for mqtt) that the client will need an implementation to interact with an mqtt / amqp client ?
This might be worth another issue.
My basic idea here is to have as much of the API as possible defined as ditto protocol for commands, such that I don't need to worry much about status codes and such. Opposed to the messages API where implementation is highly use-case and device specific, which is good since e.g. (vorto) operations implemented as messages follow a custom API.
I'll additionally require a python SDK for some devices which I plan to open-source / contribute if we'll be the firsts to implement this ;)
from ditto.
This might be worth another issue.
I agree 👍
This issue is about providing the already existing "live command" concept via the HTTP API (only triggering "live commands", not answering them).
from ditto.
I've "discovered" an interesting use-case: I'm wanting to use the ditto commands API in "live" channel, but I'd also restrict users via policy from using the "twin" channel.
This is because I'd like the twin channel to only be accessible by the machine, while the user always uses the live-channel to alter things directly. This is to ensure that data is always going through the machine and is eventually dropped if the machine is not available. This is opposed to the desired-state pattern where I place desired state information for a device to retrieve. This is meant for situations where commands expire really fast and you don't want the machine to do anything if it's currently not accessible so you don't end up altering a state in a context you don't understand / know about.
To differentiate this from messages: to reduce the complexity of the used API I'd like to use live-commands instead of messages, because I really just need to set simple configuration values which seems a bit of overkill to use the messages API for.
What do you think?
(Also this might be worth another issue, feel free to hit me in gitter if this is too off-topic)
from ditto.
@w4tsn this is something which the current policy concept explicitly don't distinguish - the twin/live channel can't be separated from each other in a policy.
For the vast majorityof use cases we saw (and still see), this is also the expected behavior: if a user may interact with a device via live commands, he should also be able to "fall back" to the persisted twin state if e.g. the device is currently not offline.
I also fear that this would make (the already quite complex) policies even more complex.
So to be honest: I have my doubts that this would be desirable for the Ditto project to provide.
from ditto.
Related Issues (20)
- mutiple ditto instance HOT 3
- Behavior of search/things API when 'indexedFieldsLimiting' feature is enabled HOT 1
- Header placeholders could not be resolved in connection HOT 2
- EndPoint HOT 7
- Incorrect template for sudo modifyPolicy piggybackCommand body HOT 2
- What is the Incoming script for sending multiple signal from the device(via mqtt connection) to the different path in the things? HOT 9
- Cannot retrieve entity at revision HOT 2
- Things UI in ditto HOT 3
- Policy anounsments not working when connection is using namespace filtering HOT 2
- Enhance conditional updates for merge/PATCH to specify different conditions for parts of the patch
- nginx timeout is not configurable in helm chart
- Connection extraField Enrichment. HOT 7
- Connection target topics with mixed filters and enrichment may fail to publish message HOT 4
- Using some placeholders in RQL "filters" for connection "targets" is not possible
- SSL kafka connection configuration HOT 3
- ImplicitThingCreation configuration HOT 7
- Removing fields in a merge update with a regex does not work in several cases
- How to access Hono Services from Outside the its Hosted VM
- Configuring "oauth2" based authentication for "devops" access does not allow to use a different OpenID connect provider
- 401 not authorized when using Nginx and helm deployment HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ditto.