Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Twin: Provided json is not a valid 'tags' or 'properties' object: arrays are not supported. #65

Closed
JohnKozell opened this issue Mar 4, 2017 · 4 comments
Assignees
Labels
question Further information is requested.

Comments

@JohnKozell
Copy link

It appears that it arrays are not accommodated on desired properties.
Is this on the roadmap?

-John

@tameraw tameraw added the question Further information is requested. label Mar 6, 2017
@tameraw tameraw assigned olivierbloch and unassigned fsautomata Mar 6, 2017
@olivierbloch
Copy link
Contributor

Hi @JohnKozell
Arrays are not supported in Device Twins (you can find details here) and we don't have it in the roadmap yet.
Can you please let us know if that is a blocking issue for you and what scenario you have in mind for the feature.
Thanks

@tameraw tameraw closed this as completed Mar 17, 2017
@JohnKozell
Copy link
Author

Hi Olivier, sorry for the delay.

My goal would be to minimize the amount of configuration information in the actual device, to provide least cost and maximum agility when reconfiguring devices.
In my case, the device (Raspberry Pi) connects to multiple microcontrollers, each having several sensors. Each of these microcontrollers and sensors are associated with names, hardware addresses, etc. This leads to hierarchical and repeating groups of configuration data.

Here is an simplified example of my configuration data:

{
  "Name": "boiler",
  "Collectors": [
    {
      "Name": "zones",
      "Address": 8,
      "MaxDevices": 8,
      "Devices": [
        {
          "Address": 0,
          "Name": "hotwater",
          "Type": "Valve"
        },
        {
          "Address": 1,
          "Name": "mastbath",
          "Type": "Valve"
        },
        {
          "Address": 2,
          "Name": "attic",
          "Type": "Valve"
        }
      ]
    },
    {
      "Name": "pumps",
      "Address": 9,
      "MaxDevices": 8,
      "Devices": [
        {
          "Address": 0,
          "Name": "pump1",
          "Type": "Pump"
        },
        {
          "Address": 1,
          "Name": "pump2",
          "Type": "Pump"
        },
        {
          "Address": 2,
          "Name": "pump3",
          "Type": "Pump"
        }
      ]
    }
  ]
}

@toolboc
Copy link
Member

toolboc commented Feb 19, 2018

We are facing a similar issue to @JohnKozell .
Essentially, we need to represent a list of units accessible from a module on the edge. Creating a unique setting for each device does not make sense as devices may or may not be available. For the time being, we are considering stringifiying a List to represent a collection and parsing that value out on the edge into a collection.

@clauney
Copy link

clauney commented May 11, 2018

We have similar use cases to the above. As a workaround, we can change how we're storing data in our code, but there are some operations that are vastly easier and cleaner with lists. It's disappointing that this still isn't (never will be?) supported.

anushprabhu pushed a commit to anushprabhu/azure-iot-sdk-csharp that referenced this issue Sep 13, 2018
CIPop pushed a commit to CIPop/azure-iot-sdk-csharp that referenced this issue Oct 5, 2018
CIPop pushed a commit to CIPop/azure-iot-sdk-csharp that referenced this issue Oct 8, 2018
CIPop pushed a commit to CIPop/azure-iot-sdk-csharp that referenced this issue Oct 9, 2018
CIPop pushed a commit to CIPop/azure-iot-sdk-csharp that referenced this issue Oct 9, 2018
CIPop added a commit that referenced this issue Oct 9, 2018
* Merge pull request #66 from Azure/alextolp/setcompletedsync

Setting CompletedSynchronously everywhere

* Provisioning MQTT transport using the ExecutorTaskScheduler.

* Device MQTT transport using the ExecutorTaskScheduler.

* Removing ConcurrentObjectPool.

* Merge pull request #63 from Azure/ravokkar/tpmamqpws-tracing

Add client side tracing to the TPM over AMQP/WS scenario

* Merge pull request #64 from Azure/alextolp/amqpsyncfix

AMQP - handle sync completion

* Merge pull request #65 from Azure/alextolp/amqpwsaddlogs

Add logs for amqp ws tpm

* Fixing synchronous completions for AMQP.

* Adding test execution note.

* Changing build order of netfx.
timstewartm pushed a commit to timstewartm/azure-iot-sdk-csharp that referenced this issue May 30, 2024
* Merge pull request Azure#66 from Azure/alextolp/setcompletedsync

Setting CompletedSynchronously everywhere

* Provisioning MQTT transport using the ExecutorTaskScheduler.

* Device MQTT transport using the ExecutorTaskScheduler.

* Removing ConcurrentObjectPool.

* Merge pull request Azure#63 from Azure/ravokkar/tpmamqpws-tracing

Add client side tracing to the TPM over AMQP/WS scenario

* Merge pull request Azure#64 from Azure/alextolp/amqpsyncfix

AMQP - handle sync completion

* Merge pull request Azure#65 from Azure/alextolp/amqpwsaddlogs

Add logs for amqp ws tpm

* Fixing synchronous completions for AMQP.

* Adding test execution note.

* Changing build order of netfx.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested.
Projects
None yet
Development

No branches or pull requests

6 participants