Smart meters and CBUS Issues

Hi Guys,

Just wanting to quickly run past a question to everyone. Has anyone had to deal with any interference issues caused by these new Smart Meters being rolled out. One I'm looking at now is a Citipower Sprint 200 (radio mesh system, I think it runs at about 900+ Mhz).

Reason I ask is I'm looking at a dead stable CBUS installation with an equally stable Ness M1 setup hooked to a HVAC system. The automation is basically spot on with no stay messages on the cbus. Its a solid system and has been for a long time.

Citipower switched the interval meter for a smart meter and we have found "ghost events" have started. Not much so far but caused the HVAC to activate by itself which is a major no no. That cannot happen based on the programming and configuration, its well isolated from accidental activation because of the concerns around this system.

The M1 controls a relay wired to the HVAC main-board so unless it got hit with high levels of EM or perhaps AC spikes I can't see a root cause here. Thoroughly checked the connections and all is good.

Anyway, a while back I spoke to a colleague that had hit similar issues with the early interval meters and CBUS. I'm wondering if we could have something similar happening here?

Only electrical change that I can identify is citipower ripping out the perfectly good interval meter and putting in one of their own radio mesh smart meters. So far I've found out it does generate both polling events and burst transmissions on a regular basis so there is a possibility the issue is caused by interference in one of the mentioned systems.

Anyway, just after thoughts or any similar experiences that might help diagnose this issue, particularly if you've encountered something similar?

 

Is your C-Bus system wired, wireless or a mixture?

 

The system is completely wired.

Ok, going on the diagnostics I took the other day before posting.

I had the CBUS toolkit running and logging and it did not record a CBUS trigger event. It did record a message coming from the M1 when the HVAC run relay was activated. So toolkit reported no buttons pressed to activate the HVAC and no key rules fired in the M1 (the M1 triggers a CBUS group for each major rule that impacts CBUS in order to confirm that a rule fired).

I've check and rechecked the programming. Everything looks good.

I think EMI has hit either the M1 data bus or HVAC remote switch wiring, given I did not see a trigger event in the application log. However....
A key concern I have is that I noticed some time ago that if I directly telnet into a CNI and start issuing CBUS commands manually without providing a proper 2's compliment checksum, the CNI still issues the command onto the network but does not record it through toolkit (i.e. It might be that toolkit recognises them as invalid and ignores them but not the actual relay boards which respond to the invalid command). If that observation is right, I suspect that if EMI did corrupt or generate a message even if the message was only partially valid it could still trigger "something" to happen. In this case, yes I'd have to see what was going on at a "lower" level (diagnostic tool) than the app log as toolkit would not record the event.

I'd be buggered how I would isolate this and debug it as the problem is "random" and intermittent and I cannot even get precise information from citipower on when their transmitters are active other than every 4 hours plus or minus 40 minutes for 1.5 seconds "we think" but cannot be sure.

The cbus diagnostic tool would pump out so much data and without knowing when the smart meter was doing its "thing" there would be no way to sensibly work out a diagnostic process.

Hence the hope that someone else had been through it before. I suspect the problem is ghost event (triggering on the odd light) would be generally ignored by users as many other installers think cbus is not that reliable (I disagree with this myself as if its configured right it will work pretty much flawlessly) but if they have that attitude they may discount such interference issues as unreliable cbus again and not try to solve it....

 

So far, it still does not sound like a C-Bus issue.

This sounds plausible.

It is not possible to issue a command onto C-Bus with an invalid checksum. From telnet (or any other client for a CNI or PCI) you can send a command with no checksum (as long as the PCI/CNI is expecting this) and the PCI/CNI will add a checksum before sending it onto C-Bus.

You can also send a command to the PCI/CNI with a checksum (again, as long as the PCI/CNI is expecting this) and the PCI/CNI will check that your checksum is correct and if it is, strip off this checksum and add a new checksum before sending it onto C-Bus. If the checksum you send is wrong, the command will be rejected.

If you can replicate your observation, please provide exact details so we can replicate it here.

When a message is sent onto C-Bus, all devices to which it is addressed will acknowledge the command. If even a single device sees a corrupted message, the message will be rejected and all C-Bus devices will ignore it.

The scenario you are describing should be impossible, and has certainly never been demonstrated.

C-Bus is very reliable when installed correctly.

If you don't see a message reported in the Diagnostic Utility log, then it didn't happen (in the sense that no devices would have seen it and acted on it).

 

Not sure if this suggestion helps but I had something similar to these "ghost" events happen not long ago.
In my case, L5108RELVP's were being affected, which in turn would trigger all sorts of loads ranging from air conditioning zones to inputs into security system.
Anyway, to cut a long story short, we determined that the issues were all caused by a replacement switch mode power supply that had been poorly shielded and was affecting the Cbus system in random ways. Surprisingly, this power supply was driving only one of the motorised doors throughout this place, amongst several.
At a glance, this sounds similar to what you're going through?

 

hi grasshopper,
Many I asked how did were you able to identify the issue with the L5108RELVP (how did you test it and verify the problem)? I'd like to run any similar tests to make sure. Again nothing has changed with the CBUS side but I'd like to be sure and check absolutely everything I can.

Darren,
Sorry I've been meaning to get back to your comment about checksum as I've observed I believe something quite different. I do have a program I've written that exploits the checksum issue I am intended to show you a sample but first I want to setup a "example" project to make it clearer what I've found and it behaves as I think. Hopefully will respond soon, sorry my CBUS development work has been on hold for a bit.

In terms of the original problem, I still have not resolved the above issue unfortunately, however I am more and more suspecting its caused by the EMI from the smart meter and the EMI is hitting the Ness equipment as the failures are consistent with certain "commands" that the Ness is responsible for. The issues occur usually around the evening meter "transmission" window of the smart meter.
i.e. My thinking is if certain "rules" were fired by accident it would match up with the failures I've seen. i.e. ac activating is a rule, garage door opening is a rule, although there is no registered "button" presses it does not mean the rule could not fire if there was interference causing a false positive voltage somewhere. I may need to have a chat with Ness about my thinking. I really wish it was more consistent so I could start to formulate a solid theory.

 

smart meter at fault

Just an update.

We had an interference specialist look at things and he was unable to find any source of interference in our systems, any issues with power supplies would have been identified. From what was found and what he said I'm certain now its the distributors Sprint 200 smart meter that's at fault. The things don't seem to be built well.

The smart meter has been installed within range of both systems particularly the Ness M1. We've also found out they run them overpowered, output is at a full 1000mW for just one transmitter which is ridiculous, totally unnecessary amount of power for its purpose.

The faults occur within range of data transmissions and as I see it the problem occurs when ordinary security / lighting data is moving through the bus when the meter "transmits" its data. Hence the intermittent nature.

Now looking for ideas on how to resolve it, as the distributors is not willing to remove the meter and replace it with the previous perfectly fine interval meter. (I guess they are worried they will have to pull these out of every job if people realise they are a major source of interference)

Anyway that's where its at. Cause identified, culprit organisation not wanting to man up, solution... not sure.

 

You could always try temporarily putting a Faraday cage around the smart meter. I assume that they don't actually read the data from them that often and it might help in nailing down the issue. Log the C-Bus traffic during this time. If everything works just fine then you'd have confirmed the source of your problem. If things misbehave the log will show which device was affected and you may be able to shield just that particular device.

 

hey another thread I forgot to respond to, and stumbled onto my own post now investigating whether iZone is experience similar types of interference.

We solve the original problem in the end. Citipower organised to reduce the meter output from 1000mw to the minimum output from memory I think was about 380mW. As soon as this was done the problem went away!

But yeh.. if you hit a similar issue, consider contacting the distributor and asking for a reduction of output power to the minimum the meter will reliability connect at. You'll probably get blank stares until you reach someone technical that understands that the metre actually can be configured remotely but persistence paid off for us.

p.s. we added a Faraday cage too later around the sensitive equipment just encase they reset the meter.