Ah, that sucks...
I will post there to keep the forum clean.

What about my 2nd question? I thought each time I manually turn something ON/OFF the module will send this to the interface - like an 'event'. Is that not so?

_________________
Best regards,
QmQ

No – the modules don’t send events.
On the other hand, interface is not able to receive commands!
Interface has no PLC-BUS address. So it is also not possible to send a command from scene-module to interface!

PLCBUSguru

_________________
www.p-b-e.de

So how do you guys implement a 'live' view of the entire house? Constant polling? If so - how often?

_________________
Best regards,
QmQ

That is the 1 million dollars question.

You can use the "GET_ONLY_ON_ID" message to get status of up to 16 units in apx. 2 seconds (all units for a specific home code)

Two problems here:
1. This generates a lot of traffic (Not sure why this is an issue, but PLCBUSGuru claims it is so we should believe him)
2. Sending commands too frequent causes the interface to get very very hot, thus it will stop working for a relatively long period of time until it cools down. There is no indication for heat inside the interface module so you can't measure this unless you implement your own temperature sensor separately.

If it is a must, I'd suggest defining very well those times you need to display the live status and for how long.

Personally, I think allowing a micro module to send status upon local event is all that's missing from making this a great alternative and competition for other technologies out there.

I think this is pure marketing decision, as all non scenario micro modules have a cheaper version of the chip (red) which can only respond a simple ack upon receiving a command.

-Buster

Ah, well, that sucks big time!

So, in points:

1. 'Big traffic' - Can PLCBUSGuru explain? I don't see how this could have negative impact..
2. Yes, I have stumbled upon this problem. This is even worse than #1. Have you tried cooling it down? Maybe taking the case off? Or simply using it in a low temperature environment (i.e. garage)? And maybe the most important question: does the interface get hot only when it sends commands or also when it receives them? Or maybe simply having it plugged-in (not using it) makes it hot?
3. All commands can be sent with the ACK Pulse bit. Does that have significant impact on #1? Does it make the interface hotter? This makes me wonder if it's better to:

A. Send a command with ACK to a device each time I need AND sometimes poll all the system for status with GET_ONLY_ON_ID
or
B. Send all commands without ACK and as a substitute for ACK always later send GET_ONLY_ON_ID so I not only have ACK but also other possible changes in the system

What do you think?

_________________
Best regards,
QmQ

When you have a small test environment and only the interface communicates with the modules you will have no problem, you can poll as much you want.

BUT!!
If you have a really PLC-BUS installation with scene modules or other controllers they are control the modules - e.g. a group of shutter must going up or down at the same time than you will get a problem.
All these controllers and your interface/program must share the bus!
An example:
Your program polls the home code A as PlcBuster wrote:To get nearly a “live system” you do this every 10 seconds.
So every 10 seconds the bus is occupied for 2 seconds. No other controller can send at this time any command!!
What can happen? You playing with your software and pooling the states. Maybe every 10s four home codes. Now you have occupied 80% of bus bandwidth.
At same time your wife comes in and want to switch on a light scene by an other controller.
Now - she must wait 8s.before the lights go on, or your wife stays in the darkness because the bus is occupied and the command can not reach the modules!! - Have a nice day

You must learn to handle the limited bandwidth of PLC-BUS. It is not at real time system.

I can not help you. I am not the manufacturer. I am also a user with a long time experience of PLC-BUS!!
What I know is:
Inside each module there is a capacitor and a inductor. A switch (I think a TRIAC) discharge this energy storages suddenly and generate the impulse. A lot of energy must flow through the inductor at a short time. The inductor is also a resistor and produce heat on each impulse. That’s the problem I think.
Maybe a larger inductor with same induction and smaller resistor value can solve the problem. I have never tested!

That’s not right. Red chip module can also send whole commands.
If you send a request like STATUSREQ or GET SIGNAL STRENGTH you will get more than an ACK.

PLCBUSguru

_________________
www.p-b-e.de

I was basing the assumption on the following message: viewtopic.php?p=123#p123
On second reading it appears I've over interpreted it.
Still more the reason why this is marketing only decision.



That is in fact a not so good day
I do agree that bus bandwidth must be taken into account. It is still surprising that although capable, an "event" driven solution isn't offered. Especially with all the discussed limitations (bandwidth and heating). I would wonder if SSE are working on these features for a future version of the micro modules.



From my testing it seems there's reason in this. I plan to put the unit eventually in a closed space with lots of heat generating devices, so it's kind of a problem for me. I think opening the case can help if there is proper air circulation. You could install a fan if you don't mind the noise.

Bottom line - this system will NOT update in real time.
If you require a real time, live status system, currently this is not the system for you.

What I learned about chip module is:
Each chip module must have a controller on the chip module.
Each chip module must have a firmware.
That’s must be, otherwise it will not possible to produce different modules with same chip module.

The main different between blue and red chip module is the I²C interface.
Only the blue chip module has the I²C interface to access the PLCBUS from other controllers outside the chip module.
All PLC-BUS controllers like mini controller, maxi controller, rs232 interface have a blue chip module inside. 3-Phase-Coupler has even 3 blue chip modules inside.

Technologically there is in my opinion no reason, why the modules do not send an event message when module is trigger from local switch.
The only reason is the bus bandwidth.
If each module will send a event message when it change status the bus will occupied in larger installations only by the event messages.

PLCBUSguru

_________________
www.p-b-e.de

I disagree about the bandwidth.
a command which doesn't require an ack will take only 400 ms on normal installation, 800 in 3 phase installation.
assuming no one is playing with 2 lights continuously there shouldn't be a problem even on large installations.
Most certainly much better than polling all devices on the network every time you want to refresh the screen.

I think it is not entirely trivial to implement this for both 1 and 3 phases so they decided to remove it, and they're not investing in development because of a marketing decision (perhaps they don't see this cost effective?)
In any case, most of the problems users here see if not all, are easily fixed in firmware changes, and a well defined logic.
If I had access to the firmware I believe I could prove it.

Alas I don't...

Let me get this straight:

The PC Interface doesn't have an address. So it's not like another device in the network - it's more like an eavesdropper, right? If I had 2 PC Interfaces on the same network and I would use one of them to send 'ON to module #1 with ACK' both interfaces would receive both the bus echo and the ACK reply?

Back to my important question:
Does the interface get hot only when sending commands or also on receiving them?


[EDIT]
Did someone reply and delete the message? I got a notification e-mail but there's no new posts...

_________________
Best regards,
QmQ