How to decide what a thing should be

[omezger]

Hi,

I'm designing my thingworkx aplication and have a question regarding what should be a thing.

I'll try to explain my problem with a realistic example. My industrial client has 8 industrial cool rooms (-20 to -10 °C). they are spread in their headquarters. They also have a room where the motors for the cooling equipment is hold and operated.

So far, I use 1-Wire Temperature sensors to monitor temperature on the machines, both on the cold side (the rooms) and on the warm side (the motors and pumps). Since I'm in a industrial environment and 1-Wire Bus networks dont operate very well with shielded cable, I want to keep my 1-Wire Bus short. I use a arduino nano operating the bus, filtering and sending the data to a raspberry pi. I can have up to 4 arduinos attached to a raspberry pi (via serial connection, USB). The raspberry pi is connected to the internet.

Let's say I have a rasberry pi (I) near the cool rooms, operating 2 arduinos (I.1 and I.2) and 20 sensors for the 8 cool rooms. I have another RPi near the machine room (II) with a single arduino (II.1) operating 8 sensors, one for each "fridge".

My question is, given how the equipment is spread across the client's company, what should be a thing in my thingworkx project. I assume the RPi themselves should be a thing, to be able to deploy them properly, but this doesnt give me any functionalty for gaining value of the data, since the real equipment is spread across things. Notice that RPi I will have parts of the data for any single fridge, while RPi II contains the other relevant part.

I also know that a sensor can also be a thing, as well as a fridge. The later makes more sense, since fridges are the real equipment I want to operate. I want to run asesments, visualizations, statistics and predictive algorithms on them.

Please contact me if you can help me solving this problem or if you have some recomendations.

Thank you

olmo

[jasong]

There are a lot of models you could do in ThWx but I prefer to model everything in ThWx like it really looks in the real world. Another way to think about it would be as a mirror, reflecting the actual hardware. This lends itself to standard Object Oriented programming, which may or may not be desirable.

So you could have a ThingTemplate for all gateways, which in your case is a RPi. And then one or many ThingTemplates representing you various sensors that the RPi is connected to, which a THINGNAME Property on it allowing you to set the RPi that you are connected through. So you end up with

SensorThing->RpiThing mirroring RPi <- Sensor

But that's the communication flow. It sounds like these sensors are monitoring something, and that itself coudl be considered a thing as well. So you coudl also, or at the same time, model those fridg's as things as well. And the SensorThings can have a THINGNAME Property pointing to what fridge it is a part of.So you end up with

SensorThing->RpiThing mirroring RPi <- Sensor

and also

SensorThing->FridgeThing mirroring Fridge <- Sensor

I am actually bad at explaining this stuff quickly but hopefully you get the gist here. As with all OO based designs, it lends itself to more flexibility overall at the cost of more complication.

If you application is very simple(only fridges), consistent (onl every 3 sensors per fridge), and certain not to grow in complexity (when does that ever happen!?), it might just be easier to model the fridges only, and have discrete properties for each sensor on the FridgeThing. Then your RPi itself can be a simple passthrough, not modeled. Since you can write in the JavaSDK, there are a lot of options.

Fortunately, and unfortunately, Thingworx lets you do whatever the heck you want to do. At the same time, it's very easy to rip up and retry, so if you make the wrong decision, it's not a huge hassle to redo it. Hopefully this is moderately helpful.

[omezger]

Hi,

thanks for your reply. I think I'm going to look at the solution where both the Gateways and the fridges are things. Also the sensor itself, and then use the RPi-Things as aggregators. IN this case, the fridges-thigns will live only in the thingworx platform.

thanks for pointing out the different directions, and the fact that it would be easy to redo if gone in the wrong direction.

olmo