Home Automation Domotica Forum Europe, Bwired Forum

When evaluating how I might add modbus support to domotiga, I was wondering if there are plans/support in the database design to support modules that have more then 4 endpoints at a given address? For example, the temco tstat 5E has 5 analog inputs, 5 digital outputs, 2 digital inputs all address via the modbus addressing methods of using a device address as well as a "register address" (just a numeric address).

From what I could see from the database table the one devices table will support up to 4 items... Maybe I am missing something in the database design..

Steve

Four values per device is the current number, it's 4 times more than HS
It's enough for the devices I had until now.

We could extend it, but what will be the next limit we hit?
I have a modbus device which has 12 inputs for example.
It's not practical to extend it to that number of values.

Maybe it's an option to define these Modbus device types:

Modbus Digital input port0-3
Modbus Digital output port0-3
Modbus Analog input port0-3
Modbus Counter input port0-3

Modbus Digital input port4-7
Modbus Digital output port4-7
Modbus Analog input port4-7
Modbus Counter input port4-7

Modbus Digital input port8-11
Modbus Digital output port8-11
Modbus Analog input port8-11
Modbus Counter input port8-11

So the max you can have is 12 total for each port type, and every port has it's own value field.

Don't know if ports commonly are numbered from 0 or 1, have to check.

Anyone has a better idea? Or has experience with other HA software regarding this topic.

What do you want to control/monitor with your modbus interface?
It must stay a bit practical to address the single ports too.

EDIT:
In the above example you can't just do SetDevice("Kitchen Light", "On"), because U have to specify which value/port to switch.
Just one device per port is also still a good option, using value1 as only value, the device type can define the type of input/output.

Rather then define a generic limit for the modbus devices, how would it work if one defines two devices for a giving modbus.

1): Define the modbus bus itself . This would be defined as the port that given bus is running on. This in the future could be divided into a couple of catagories:
a) modbus serial interface for RTU/ASCII communications
b) modbus tcp connections

One of the reasons for defining the bus as a individual device is that it is a shared device that has certain attributes which might include serial port speed, RTU or ASCII communcations, etc.

2) Once defining the bus, a person would be able to define devices that are attached to a bus defined by the bus as define in item 1 above.

Then it would be easier to have modules for the individual devices on the bus. Then these individual modules could be responsible for a database table for the device type. By splitting the table out to a given device type one could make use or at least make it easy to extend the database to support more of the inputs/outputs of the device. This way, the device module would be the device that is responsible for all of the queries, etc. for the device.

This has been what I have been working on when prototyping my logic in perl for MH. In that case rather then storing the data in a database, the data is stored in the object in memory.

Does this sound like something that might work?

Split devicevalues from the device itself. Make it 1:n and dynamic.
Just wait till you have a Proliphix Nt20E thermostat, it has 36 devicevalues

In my system i have 2 tables for device configuration. 1 for the device (ID, TypeID, PhysicalAddress, Location, Enabled etc) and a second for the configuration of the devicevalues (i call it different, but it comes down to the same thing): (ID, ValueID, Description, InformationTypeID, UnitID, SaveData, WebDisplay etc.).
When a device object is created it searches for the devicevalues belonging to itself and puts them in a dynamic array.

@Digit: That is how I would do it too. But we talk some more about that pretty soon Flexibility rules!

@Rene and Digit: I agree about flexibility, but I started to write the project keeping in mind that it should have as less code as possible and minor overhead... and with no written or documented preparation at all.

I think I succeeded in reaching my goal, and I did come far looking at how much hw/interfaces and different protocols are supported natively now.

But then request for modbus support came which doesn't have one interface unit doing all the communication, you can have tcp/ip and or serial devices, master and slaves, and no modbus device is that same as another regarding number and type of ports.

It's never too late to adjust the low level design, but I don't want to create a misterhouse clone either..

Would be glad to talk about the consequences of making the number of values dynamic regarding database design, and regarding displaying them on user interfaces without too much code/hassle...

We ramble about this next Sunday if time permits.