Ness/ELK M1 Levels & percentages bug.

I am having trouble with my ELK M1G (same as the NESS M1) and the way it converts group levels (0-255) to percentages. I'm using a M1 C-Bus interface version 3.

In summary I think there is a bug/coding error with the way C-Bus group levels are translated into percentages and vice versa in the ELK/NESS interface. There is a disparity between the way the levels are converted.

C-Bus uses a value range from 0 to 255 for lighting levels and other variables. The ELK/NESS system uses percentages, quite a common situation when interfacing to C-Bus.

Setting a percentage using the ELK results in the appropriate level being sent to the C-Bus system. For example setting the level to 19% via the ELK:

ELK M1XEP Debug Trace:
12:59:00 TCP SendUnkPkt 0BPCD07190086

You can see the percent of ?19? in the packet, after the '0BPCD07'. C-Bus responds with the following where you can see the sending unit is the ELK (Unit= 255 INT_ELK/ELKM1G):

C-Bus Toolkit Application log:
DateTime= 10/05/2017 12:59:02.350 App= 056 Lighting Group= 055 Balcony LEDs Unit= 255 INT_ELK/ELKM1G Event= Group ramped to 048 ( 19%) over 0 seconds

So the 19% from the ELK is converted to a group level value of 48. This comes about from the following formula as per the C-Bus specification (page 10 of http://training.clipsal.com/downloads/OpenCBus/C-Bus Quick Start Guide.pdf):

Convert from percent (0-100) to decimal (0-255)
Decimal = truncate ( (percent * 255) / 100 )

e.g. 48 = truncate (19 * 255)/100)

All good so far.

The problem is that the ELK does not always correctly convert the group levels it receives from C-Bus to the correct percentages. If a level is set by another device other than the ELK the corresponding percentage that the ELK reports is almost always not correct.

In this case the level of 48 was set by the unit Unit= 041 INT_CIS/UKUSA on the C-Bus network:

DateTime= 10/05/2017 13:00:23.823 App= 056 Lighting Group= 055 Balcony LEDs Unit= 041 INT_CIS/UKUSA Event= Group ramped to 048 ( 19%) over 0 seconds

But the ELK responds with a level of 18%, not the correct 19%:

13:00:21 TCP SendUnkPkt 0BPCD07181086

This is because the ELK is simply truncating and dividing the level value by 255. I.e. Percentage = truncate ((value/255) * 100). This is an incorrect formula for this application.

The correct formula is Percentage = truncate (((value + 2)/255) * 100), as per the C-Bus specification.

I believe that the ELK software/firmware is missing the ?+2? part of the formula.

Essentially because the values are truncated and not rounded the current formula does not always work in both directions. You need the ?+2? to mitigate the truncation.

Other examples that I tested:

ELK% -> CBus Level -> ELK%
10 25 9
11 28 10
12 30 11
13 33 12
14 35 13
15 38 14
16 40 15
17 43 16
18 45 17
19 48 18
20 51 20
21 53 20
22 56 21
23 58 22
24 61 23
25 63 24
26 66 25
27 68 26
28 71 27
29 73 28
30 76 29

While this may seem trivial for light levels it is problematic for other devices where accurate values are important. For example I use ?virtual lighting groups? in C-Bus to communicate temperatures and analogue data.

Has anyone else noticed this? Cold someone else test this to see if the get the same results?

Many thanks, Marty

System: M1G
Hardware: 0.13
Boot Version: 3.3.6
Firmware: 5.3.10
M1XEP: hardware 1.0, Boot 2.0.4, Firmware 2.0.42
M1 C-Bus Interface Rev 3.0.2

 

I'm not surprised you are seeing what you are.

I have reported many inconsistencies with the Ness mini central and the C-Bus specification to them with no action.
There doesn't appear to be enough sales for them to care. Near enough is close enough.

I realise the M1 interface is not a mini central, but from my testing some time ago they seemed to have the same problems, leading me to think they have a common heritage.

As for solving your actual issue, you might be forced to use intermediate phantom group addresses and perform your own translation in logic.

Cheers

Rohan

 

So I have had this bug confirmed by another M1G/NESS owner who is seeing exactly the same thing.

I emailed Elk and Ness but have not heard a word from either. Disappointing.

 

I spoke with Ness about this yesterday. They said they have never had anyone report this problem in the 8 years they have had the CBus interface. This, unfortunately, means it will be a low priority issue for them. But at least they are going to look into it.

 

Yeah, probably in the same way they haven't been told about all the non conforming problems that I reported to them too.

 

I gave up reporting bugs in the M1 Cbus interface years ago. The V2 was such a disaster they had to swap them all for V3's. They advertise it as an approved Cbus devices, but if that is true someone at CIS certainly dropped the ball because they certainly don't follow either the cbus time or security protocols very faithfully.

As for the percentage problem, if you read the Ness cbus interface documents they recommend you only ever test for on and off levels anyway.

 

Absolutely a load of crock. I received the same response from their tech support 'head guru' who, not naming names, would rather listen to himself rabbit on that he's never had any problems ever than hearing the fault & the steps I had taken to try to help them troubleshoot. Then after constantly calling and complaining he did a backflip after 3 months - stating that a d16 mini central/ board replacement was out.

Having wasted another day replacing the alarm and logging, the client & I still report that cbus comms drop out after a few days. Very dissapointing that the M1 has issues too as this was my next step in trying to help my client.

Frankly, now, I've given up on ness & wish Clipsal didn't stop selling their homesafe panel - it was good for what it was and foremost it worked. I'll be calling around to find an old homesafe panel to replace this ness junk.

 

I have given Ness another nudge given the comments above about their lack of responsiveness. The reply was interesting:

Are they suggesting that the C-Bus specs have changed? I am not aware of any such thing.

Will be interesting to see how quickly an update becomes available.
Marty.

 

The cbus protocol documents precede the Ness M1 cbus interface by many moons.

Someone at Ness probably decided to read them at last

 

Given NESS may actually read this thread, here is my findings from 2 years ago that I reported.

Also from my testing it would appear that the NESS M1 C-Bus interface is the same (or very similar) to the Mini Central on the D16

(Names removed to protect the innocent)

I have noticed several inconsistencies between the Clipsal HomeSafe Version and the later NESS MiniCentral version.

The issues are as follows;

1. Arm Types
The arm types between the two versions is not consistent.
HomeSafe supports more modes, and the translation to the C-Bus mode is completely different.

For both the HomeSafe and D16, it is not possible to arm Area2 unless a special lighting (not security application) command is setup.

Panel Type------ Arm Type----------------------C-Bus Arm Mode
Homesafe-----------Away Mode--------------------Armed Special
----------------------Night (Home) Mode-----------Partially Armed
----------------------Highest Level------------------Armed Special

NESS D16-----------Away Mode-------------------Fully Armed
----------------------Highest Mode-----------------Fully Armed


2. Raise Tamper & Drop Tamper
Homesafe supported, D16 not supported.

3. Raise Alarm
Homesafe supported, D16 not supported.

4. Mains Failure & Mains Restore
Homesafe supported, D16 not supported.

5. Tamper On & Tamper Off
Homesafe supported, D16 not supported.

6. Password entry succeeded & Password entry Failed
Homesafe supported, D16 not supported.

7. Soft Keypad key presses interleaved with physical keypad.
Homesafe supported, D16 not supported.

8. Homesafe manual is for D16
The manual for Homesafe is just a D16 manual with ?Clipsal5400? replacing ?NESS D16?. Because of this, the manual is full of commands that don?t work on the HomeSafe and are not even relevant to the version of firmware shipped with HomeSafe.

9. SIM branding in Toolkit
Homesafe appears in Toolkit as a generic SIM module. D16 appears as a branded module.


This is what I have found so far, and it looks to me like the D16 (MiniCentral) version was never completely implemented.
The NESS D16 manual claims the MiniCentral is a ?Fully Clipsal approved C-Bus Enabled product? and it is nowhere near a capable as the older HomeSafe version (from a C-Bus perspective).

 

The M1 cbus interface definitely does not pass on zone status messages when unarmed. To get around this I connect to the M1 from a touch screen via ethernet to get all the info I need. I posted the logic code a while ago:

http://www.cbusforums.com/forums/showthread.php?t=16018

The other option with the M1 is write a rule that triggers a re-triggerable timer (i.e. an unused output) whenever a zone you want to know about changes, then add another rule that pulses a cbus ga whenever that ouput is set. That way you can set the timer to limit the frequency of zone status chage outouts to cbus.

 

Does anyone know of a manager or something at NESS?

I have emailed NESS technical support about an update on this issue 3 times over the last few months and have never had a response, even though they initially did reply to that email address.

It's very disappointing. I see now why some people are moving away from NESS products.

 

GKNess is a member of this forum and a manager at Ness.

Try dropping him a PM and see if you get a reply.

Rohan

 

A friend is putting in C-bus and asked about an alarm system. My first thought was the M1 because of the C-Bus comparability but based on these comments I am inclined to look at other options.

What other panels do people recommend?

 

+1 - What are other gurus using/ recommending?

 

So I finally got a reply from NESS, but only after sending them an email about how disappointed I was at the lack of response, and mentioning to them that there has been some discussion about NESS support. But instead of an apology I received a somewhat sarcastic reply.

My words were obviously not kind. Maybe I am being impatient but I don't think it is unreasonable to expect a reply to emails asking for an update. All that was required was an simple apology for the lack of reply and an assurance that it is being looked into.

I'm starting to wish I had never invested in NESS products.

 

Here's an update from NESS:

Again disappointing.