(Changed) Polling period for Qubino 2 Flush (Z-wave) Relais sensors set to 30 min?

[Elsing (Markus)]

yes, did that already:

40: 10 (%)
41: 15 (sec)
42: 10 (%)
43: 15 (sec)

changing the parameters did not change the behaviour for me.

PPS: the qubino flush shutter reports the power updates, but not the state updates. I can get the qubino flush 2 relays to report the state update with a “refresh” command. It seems I don’t understand the concept really how this is supposed to work. As I said before, in the shop with other home system it reported correctly, so it looks like some config issue or binding ?

[sihui]

@Elsing

I can get the qubino flush 2 relays to report the state update with a “refresh” command.

What do you mean by that? A browser page refresh?
Actually there are no config settings to get the actual states from a device, it should work instantly … and does on my system … as long as the correct association group is set to your controller - in your case “Default Reporting Group”

[Elsing (Markus)]

@sihui yes, a refresh on HAPMIN clicking on Conf->things->device->Desciption “refresh items”, image attached.

I don’t get the updates. I am really confused about how this should be set correctly, here is my config…

[sihui]

Looks all fine … sorry, no more ideas.

[Seaside]

I had a fibaro dimmer 2 stop reporting sensor power today. Got it working again by excluding it and then readding it.

Regards s

[Elsing (Markus)]

hi, hmm, that’s another idea. I’ll try that later…

cheers, markus

[Elsing (Markus)]

Just to report, I tried excluding/including the device, no change. Did not fix the problem. Any other ideas what could be wrong ? Or is it a binding issue for the qubino device @chris ?

[Elsing (Markus)]

Ok, some progress here. I overlooked that there is a “polling period” in HABMIN to configure this. By default this is set to 30 min for the Qubino devices, which makes little sense for a power sensor. Putting this to 15 (seconds) gives me the sensor updates (Yeah). I think the default for the polling time should be updated such that the sensors get read. @chris, do you think this makes sense to change it ?

[chris (Chris Jackson)]

@Elsing

I think the default for the polling time should be updated such that the sensors get read. @chris, do you think this makes sense to change it ?

No - generally polling is bad news as it congests the network needlessly (in most cases).

You should be able to configure the device to report without polling. Normally there should be configuration options that tell the device to send every x minutes, or when the power changes by y watts. Normally you would only configure it to send when there’s a change.

I would be very surprised if the Qubino doesn’t have this feature (the Qubino devices I have definately do).

[Elsing (Markus)]

Hi @chris, the Qubino device does have those options, but they seem not to have an effect in OH2. Reporting works for the flush shutters (ZMNHCD) for me, but for the 2 relays (ZMNHBD) it doesn’t. It works as well for a FGBS001 Universal Binary Sensor for me. See discussion here. The only workaround I found was to change the polling. I do see that the network is now slower, that is true.

For all my devices I put the reporting to 15 sec (regardless of the polling interval) and >10% changes, but this seems to have no effect. I tried the Qubino 2 relays device with another home automation system in the shop, it did report immediately. So it seems there is some sort of config issue in OH2/binding somewhere for the 2 relays (ZMNHBD), but I wasn’t able to debug this. Any help welcome.

[chris (Chris Jackson)]

@Elsing

but they seem not to have an effect in OH2.

What do you mean? The reporting is a function of the device - the device should send the same message as the poll, but without the binding having to poll.

If the configuration in the device doesn’t work, then either the device has a problem, or the configuration isn’t right. You should capture a log to see if the device is sending anything - if it is, then we need to analyse it to make sure it’s what the binding is expecting to see, and if it’s not, we’ll sort out the binding to fix this.

Adding polling is not the solution - getting the device reporting to work is…

This may be related to the way Qubino decides to send multi-channel data. Did you do all the configuration of this device within OH2 or have you need using OH1 to do the initial inclusion etc?

[Elsing (Markus)]

Hi @Chris, I agree with you, I will try to get some debug logs to see later today. I agree, it looks like there is some sort of config problem, either on my side or on the binding.

Concerning your question, I am including the device with the USB controller, I normally discover the device in the paper UI, the config then I do in HABMIN (OH2) (parameters,…), for the UI and for running the system etc I have items/rules/sitemap… config files.

[Elsing (Markus)]

Hi @Chris, here is how far I got it with looking into the logfiles. I think I have a good hint on what is going on. The Power_meter updates in the logfiles are for the Qubino Flush 2 Relays are for endpoint=0 (which is the overall power), but not for endpoints=1 and endpoints=2, which are the individual switches. I do see in the logfiles lines like this:

2017-01-08 17:04:57.605 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 2: Application Command Request (ALIVE:DONE)
2017-01-08 17:04:57.606 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 2: Starting initialisation from DONE
2017-01-08 17:04:57.606 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 2: Incoming command class METER
2017-01-08 17:04:57.606 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 2: Received METER command V3
2017-01-08 17:04:57.606 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 2: Meter: Type=Electric(1), Scale=W(2), Value=17.3
2017-01-08 17:04:57.606 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveMeterValueEvent
2017-01-08 17:04:57.606 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Got an event from Z-Wave network: ZWaveMeterValueEvent
2017-01-08 17:04:57.606 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Got a value event from Z-Wave network, endpoint = 0, command class = METER, value = 17.3
2017-01-08 17:04:57.607 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Updating channel state zwave:device:c1977c1d:node2:meter_watts to 17.3 [DecimalType]
2017-01-08 17:04:57.607 [DEBUG] [ternal.converter.ZWaveMeterConverter] - Not the right scale E_KWh <> E_W

which is endpoint=0 and the command class is METER (!!). It looks to me the values are for the individual endpoints though ??? There are in fact tons of endpoint=0 messages for the nodes in the lofile like this, so the Qubino is reporting as it should, but it ends up wrongly.

One possible other issue I see is a mismatch comment E_KWh<> E_W in the logilfe during init phase (nodes get initialised). This looks like a bug to me, as the message gives scale=W.

Later on I found a different pattern for a Qubino Flush 2 Relays:

2017-01-08 17:15:00.426 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 57: Application Command Request (ALIVE:DONE)
2017-01-08 17:15:00.427 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 57: Starting initialisation from DONE
2017-01-08 17:15:00.427 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@63ef849a already registered
2017-01-08 17:15:00.427 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 57: Incoming command class METER
2017-01-08 17:15:00.427 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 57: Received METER command V3
2017-01-08 17:15:00.427 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 57: Meter: Type=Electric(1), Scale=W(2), Value=30.2
2017-01-08 17:15:00.427 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveMeterValueEvent

and the nothing for this node anymore. I found this only once.

Then I tried turning on/off switches (from the Basic UI) to trigger power meter updates:

2017-01-08 17:48:40.888 [ItemCommandEvent ] - Item ‘Light_FF_DiningRoom_Rear’ received command ON
2017-01-08 17:48:40.907 [ItemStateChangedEvent ] - Light_FF_DiningRoom_Rear changed from OFF to ON
2017-01-08 17:48:41.913 [ItemCommandEvent ] - Item ‘Light_FF_LivingRoom_Sofa’ received command OFF
2017-01-08 17:48:41.930 [ItemStateChangedEvent ] - Light_FF_LivingRoom_Sofa changed from ON to OFF
2017-01-08 17:48:42.755 [ItemCommandEvent ] - Item ‘Light_SF_Mezzanine_Stairs’ received command ON
2017-01-08 17:48:42.788 [ItemStateChangedEvent ] - Light_SF_Mezzanine_Stairs changed from OFF to ON
2017-01-08 17:48:44.277 [ItemCommandEvent ] - Item ‘Light_FF_LivingRoom_Rear’ received command OFF
2017-01-08 17:48:44.282 [ItemStateChangedEvent ] - Light_FF_LivingRoom_Rear changed from ON to OFF
2017-01-08 17:48:44.851 [ItemCommandEvent ] - Item ‘Light_FF_Stairs’ received command ON
2017-01-08 17:48:44.857 [ItemStateChangedEvent ] - Light_FF_Stairs changed from OFF to ON
2017-01-08 17:48:45.591 [ItemCommandEvent ] - Item ‘Light_FF_GuestBedroom_Sofa’ received command ON
2017-01-08 17:48:45.626 [ItemStateChangedEvent ] - Light_FF_GuestBedroom_Sofa changed from OFF to ON
2017-01-08 17:48:46.845 [ItemCommandEvent ] - Item ‘Light_FF_GuestBedroom_Rear’ received command OFF
2017-01-08 17:48:46.848 [ItemStateChangedEvent ] - Light_FF_GuestBedroom_Rear changed from ON to OFF

This triggered 2 change events:

2017-01-08 17:49:16.371 [ItemStateChangedEvent ] - Light_FF_LivingRoom_Rear_Power changed from 9.6 to 0
2017-01-08 17:49:17.652 [ItemStateChangedEvent ] - Light_FF_LivingRoom_Sofa_Power changed from 18.4 to 0

I first did not understand this, but after some digging there was (by change) a POLL event in between:

2017-01-08 17:49:11.165 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 57: Polling…
2017-01-08 17:49:11.165 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 57: Polling zwave:device:c1977c1d:node57:switch_binary
2017-01-08 17:49:11.165 [DEBUG] [converter.ZWaveBinarySwitchConverter] - NODE 57: Generating poll message for SWITCH_BINARY, endpoint 0
2017-01-08 17:49:11.165 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - NODE 57: Creating new message for application command SWITCH_BINARY_GET
…

and this leads to

2017-01-08 17:49:16.358 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 57: Application Command Request (ALIVE:DONE)
2017-01-08 17:49:16.358 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 57: Starting initialisation from DONE
2017-01-08 17:49:16.358 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@69978b4b already registered
2017-01-08 17:49:16.358 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 57: Incoming command class MULTI_INSTANCE
2017-01-08 17:49:16.358 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 57: Received MULTI_INSTANCE command V2
2017-01-08 17:49:16.358 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 57: Requested Command Class = METER (0x32)
2017-01-08 17:49:16.358 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 57: Endpoint = 1, calling handleApplicationCommandRequest.
2017-01-08 17:49:16.358 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 57: Received METER command V3
2017-01-08 17:49:16.358 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 57: Meter: Type=Electric(1), Scale=W(2), Value=0E+1
2017-01-08 17:49:16.358 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveMeterValueEvent
2017-01-08 17:49:16.358 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 57: Got an event from Z-Wave network: ZWaveMeterValueEvent
2017-01-08 17:49:16.358 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 57: Got a value event from Z-Wave network, endpoint = 1, command class = METER, value = 0E+1
2017-01-08 17:49:16.358 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 57: Updating channel state zwave:device:c1977c1d:node57:meter_watts1 to 0 [DecimalType]
2017-01-08 17:49:16.359 [DEBUG] [ternal.converter.ZWaveMeterConverter] - Not the right scale E_KWh <> E_W

similar for endpoint 2 afterwards. This is command is now class MULTI_INSTANCE, while the others are METER ??? It seems like this is the reason why the power_meter updates for endpoints 1 and 2 are ending up as channel updates for endpoint 0 ? Is this a mis-config of the Qubino, I don’t see where to configure this differently ? Or something else ?

---

Btw, there is a frequent ERROR message in the logfile, here an example for a Qubino Flush Shutter (!), the pattern is:

2017-01-08 17:05:52.394 [ERROR] [ocol.ZWaveController$ZWaveSendThread] - NODE 29: Timeout while sending message. Requeueing - 1 attempts left!
2017-01-08 17:05:52.394 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 29: Got an error while sending data. Resending message.
2017-01-08 17:05:52.394 [DEBUG] [ve.internal.protocol.ZWaveController] - Message queued. Queue length = 117. Queue={}
2017-01-08 17:05:52.395 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - Took message from queue for sending. Queue length = 116
2017-01-08 17:05:52.395 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0A 00 13 1D 03 70 05 56 25 01 FF
2017-01-08 17:05:52.395 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 29: Sending REQUEST Message = 01 0A 00 13 1D 03 70 05 56 25 01 FF
2017-01-08 17:05:52.404 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8
2017-01-08 17:05:52.404 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2017-01-08 17:05:52.404 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 04 01 13 01 E8
2017-01-08 17:05:52.404 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 04 01 13 01 E8
2017-01-08 17:05:52.404 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Response[0x01], priority=High, dest=255, callback=0, payload=01
2017-01-08 17:05:52.405 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 29: Sent Data successfully placed on stack.
2017-01-08 17:05:52.420 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 01 00 00 02 E8
2017-01-08 17:05:52.420 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2017-01-08 17:05:52.420 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 01 00 00 02 00 00 E6
2017-01-08 17:05:52.420 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 13 01 00 00 02 00 00 E6
2017-01-08 17:05:52.420 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=01 00 00 02
2017-01-08 17:05:52.420 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 29: SendData Request. CallBack ID = 1, Status = Transmission complete and ACK received(0)
2017-01-08 17:05:52.421 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Config, dest=29, callback=
1, payload=1D 03 70 05 56
2017-01-08 17:05:52.421 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0
, payload=01 00 00 02
2017-01-08 17:05:52.421 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=SendData, callback id=1, expected=ApplicationCommandHandler, cancelled=false MIS
MATCH

It does not look to me this is related to the power meter issue, but I thought this might be interesting.

[chris (Chris Jackson)]

@Elsing

There are in fact tons of endpoint=0 messages for the nodes in the lofile like this, so the Qubino is reporting as it should, but it ends up wrongly.

Why do you say it is “reporting as it should” - it looks like it’s reporting to endpoint 0 - it’s VERY unlikely that the binding will report the endpoint wrong but the logging you provided doesn’t give the received message so I can’t be 100% sure.

I suspect that this is an issue with the configuration of the multi-channel-association that I’m working on elsewhere. Unless the MC association is set correctly, the device will only ever report endpoint 0.

@Elsing

One possible other issue I see is a mismatch comment E_KWh<> E_W in the logilfe during init phase (nodes get initialised). This looks like a bug to me, as the message gives scale=W.

This is fine - no problem at all. This is simply a debug message and doesn’t indicate a problem. In fact you can see in the log that the item is being updated correctly.

So, I think the issue will be with the MC association class which is needed to get the device reporting with the MC encap class. It will likely take a little time to get this working as I’m on holiday - you could try the latest binding to see if it configures the associations better, but I’m not sure it’s 100% right yet.

If possible when providing logs, please ensure that the received data packets are provided - otherwise it’s difficult to process and see what’s happening.

[Elsing (Markus)]

Hi @Chris, thanks for the fast reply ! Next time I will try to capture the ZWave messages, in fact I have the logfiles still and I will try to dig them out later for you (I am still learning and wasn’t identifying it in the logs).

Do you understand why the device polling produces an update with the right MC association ?

I will try a new version of the binding this evening and let you know in case.

[chris (Chris Jackson)]

@Elsing

Do you understand why the device polling produces an update with the right MC association ?

Yes. Polling polls the different endpoints using multi-channel encapsulation, and the device MUST respond using multi-channel encapsulation. However when the device sends unsolicited data, it doesn’t - it will send without the encapsulaton unless the multi-channel association is configured and this isn’t working properly at the moment.

See -:

New Fibaro Switch FGS-223 is driving me nuts

I’ve made a change, but I’m not sure it will work for you yet. Since this only affects group 1, and there are other problems preventing you changing group 1, this change may not actually do anything. If you exclude the device and add it back it might work. Make sure you keep a log so we can see what happened during the initialisation if it didn’t work.

and

How to access different endpoints?

Hi, I have a Qubino flush 2 switch (ZMNHBD) which is supported by the Zwave binding (1.8.0). This Zwave device has just two switches with each its own endpoint (I think). My question, how can you select the right switch/endpoint? My item file now looks like this: Switch Z_Kitchen_Switch1 “switch1” { zwave=“17:command=switch_binary” } Switch Z_Kitchen_Switch2 “switch2” { zwave=“17:command=basic” } This way I can d…

and

Qubino ZMNHBD1 Flush 2 not reporting separate switches

Hi there, I’ve just installed a second Qubino Flush 2 Relay and added it to my Zwave network. I’m now having trouble receiving status updated for the two separate switches it contains when using the hardware switch. When toggling the switch, the Qubino correctly toggles the connected light. The Zwave binding receives a status update for switch_binary. However, this channel reports changes for either of the hardware switches. There are separate channels switch_binary1 and switch_binary2, but tho…

[Elsing (Markus)]

Hi @Chris, I updated the binding, no change in the behaviour (as you expected).

Below a piece of the logfile with the message this time included, I hope. I don’t understand what it means, hope you find this useful:

21:42:35.572 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 10 00 04 00 39 0A 32 02 21 34 00 00 01 25 00 00 D9
21:42:35.573 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
21:42:35.573 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 10 00 04 00 39 0A 32 02 21 34 00 00 01 25 00 00 D9
21:42:35.573 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 10 00 04 00 39 0A 32 02 21 34 00 00 01 25 00 00 D9
21:42:35.573 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 39 0A 32 02 21 34 00 00 01 25 00 00
21:42:35.573 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 57: Application Command Request (ALIVE:DONE)
21:42:35.573 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 57: Starting initialisation from DONE
21:42:35.573 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@1fd05ca4 already registered
21:42:35.573 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 57: Incoming command class METER
21:42:35.573 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 57: Received METER command V3
21:42:35.573 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 57: Meter: Type=Electric(1), Scale=W(2), Value=29.3
21:42:35.573 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveMeterValueEvent
21:42:35.573 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 57: Got an event from Z-Wave network: ZWaveMeterValueEvent
21:42:35.573 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 57: Got a value event from Z-Wave network, endpoint = 0, command class = METER, value = 29.3
21:42:35.574 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 57: Updating channel state zwave:device:c1977c1d:node57:meter_watts to 29.3 [DecimalType]
21:42:35.574 [DEBUG] [ternal.converter.ZWaveMeterConverter] - Not the right scale E_KWh <> E_W

[automatic (Allen)]

I am experiencing a similar issue with Qubino 2 Relays (I have 2 modules installed):

• Unit 1 reports state from 1 of 2 switches (i.e second switch does not report when manually triggered). Power reporting works.

• Unit 2 does not report anything (neither power nor switch states)

Both units process input from the controller without any problems (i.e. on/off works fine).

I have a few Qubino 1 Relay modules, they all report status/power without any problems. Network looks good according to Habmin Network Viewer.

Any thoughts on what may be going on here?

[vossivossi]

@automatic

Any thoughts on what may be going on here?

Yes, sounds like the old problem with the multi instance associations. The solution for me was to exclude the device and reinclude it with Habmin with a network wide inclusion. The inclusion should be done with the OH Release 2.0.0 or a newer snpashot version (do not use the dev branch Z-Wave binding as it still has this problem).

[automatic (Allen)]

@vossivossi

The solution for me was to exclude the device and reinclude it with Habmin with a network wide inclusion. The inclusion should be done with the OH Release 2.0.0 or a newer snpashot version

That is exactly what I did. Reincluded via Habmin (via magnifying glass with plus sign inside) and am using current snapshot version. Despite apparently having done the same thing as you, I am getting different results…