This trigger no longer working - complaining about the operator needing changing
-
I just unpaired a Fibaro motion sensor from an Ezlo hub and paired it to my Vera hub instead. I already had an existing rule and just tried to fix it by changing the now "unknown" device to the "new" device etc.
But the trigger looks wrong and if I attempted to correct it I get a message from MSR about removing none default conditions.
Trigger:
I think the "Is True" part now needs changing to -- value of 1 instead. However when I select the -- operator I see this message.
Here is the rest of the rule:
Constraints:
Set Reaction:
Reset Reaction:
In MSR for Vera devices I now only seem to have the Extended attribute options available in the menu, so the values for a tripped or not tripped motion sensor for example are always going to be 1 or 0
Seems in the past however for Vera devices you could select another option rather than an extended attribute (One that MSR created for the user to make it "easier") and use True or False and it looks like it was using that also when this motion sensor device was previously paired to the Ezlo hub. If that makes sense?
I just found this old screenshot on the forum on an old post. I think its the binary_sensor.state (primary) I am thinking of that we used in the past with True or False. Those have now gone etc.
Thanks
-
"Changing the operator on this condition will remove the non-default condition options currently set."
It's just telling you that the conditions options (under the dot-dot-dot button/icon) are going to be cleared because the operator is changing. That's because not every condition option is available for every operator. If you choose a Reactor-defined capability and attribute, it will recognize the operator's required type (so things like is TRUE and is FALSE will be allowed for attributes known to be boolean). When you use any extended attribute, like
x_vera_anything.anything(thex_verapart being the clue that's an extended capability and attribute), that system's native type governs, and for Vera, that's a string, so is TRUE and is FALSE don't apply.General recommendation is don't use the extended attributes when a Reactor-defined attribute is available.
To look beyond this, you'd need to post the attribute list for the device for starters. There's a Copy Attributes button in the entity detail. Use that, and paste the output here.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
Think I might have to delete the rule and start again with some slightly different logic.
Trigger:
Motion is detected in the Hallway
Constraints: (Conditions)
LUX Level <= 100
Motion Sensor = Disarmed
A virtual switch (Dark Mode) = OFFSet Reaction:
If Vera is in Home Mode then set the Hallway light to 40%
If Vera is in Night Mode then set the Hallway light to 20%
Reset Reaction:
Turn the light OFF
I think this rule worked in the past but it was disabled for a while so maybe not. Don't think I arm this motion sensor for any reason, perhaps I need two rules instead now.
-
Don't scorch the earth yet. Let's figure it out.
Post the attribute list for the device for starters. There's a Copy Attributes button in the entity detail. Use that, and paste the output here.
-
"Changing the operator on this condition will remove the non-default condition options currently set."
It's just telling you that the conditions options (under the dot-dot-dot button/icon) are going to be cleared because the operator is changing. That's because not every condition option is available for every operator. If you choose a Reactor-defined capability and attribute, it will recognize the operator's required type (so things like is TRUE and is FALSE will be allowed for attributes known to be boolean). When you use any extended attribute, like
x_vera_anything.anything(thex_verapart being the clue that's an extended capability and attribute), that system's native type governs, and for Vera, that's a string, so is TRUE and is FALSE don't apply.General recommendation is don't use the extended attributes when a Reactor-defined attribute is available.
To look beyond this, you'd need to post the attribute list for the device for starters. There's a Copy Attributes button in the entity detail. Use that, and paste the output here.
@toggledbits said in This trigger no longer working - complaining about the operator needing changing:
It's just telling you that the conditions options (under the dot-dot-dot button/icon) are going to be cleared because the operator is changing.
oh is that all? I thought it meant it was going to start deleting some of the lower Constraints in the rule.
-
"Changing the operator on this condition will remove the non-default condition options currently set."
It's just telling you that the conditions options (under the dot-dot-dot button/icon) are going to be cleared because the operator is changing. That's because not every condition option is available for every operator. If you choose a Reactor-defined capability and attribute, it will recognize the operator's required type (so things like is TRUE and is FALSE will be allowed for attributes known to be boolean). When you use any extended attribute, like
x_vera_anything.anything(thex_verapart being the clue that's an extended capability and attribute), that system's native type governs, and for Vera, that's a string, so is TRUE and is FALSE don't apply.General recommendation is don't use the extended attributes when a Reactor-defined attribute is available.
To look beyond this, you'd need to post the attribute list for the device for starters. There's a Copy Attributes button in the entity detail. Use that, and paste the output here.
@toggledbits said in This trigger no longer working - complaining about the operator needing changing:
If you choose a Reactor-defined capability and attribute, it will recognize the operator's required type (so things like is TRUE and is FALSE will be allowed for attributes known to be boolean)
Yes that's right that's how it use to work. However now I am noticing I don't seem to have these Reactor defined capability and attribute anymore in that menu. I just seem to have the extended attributes only now. I will post the attributes list of this device in a moment.
-
"Changing the operator on this condition will remove the non-default condition options currently set."
It's just telling you that the conditions options (under the dot-dot-dot button/icon) are going to be cleared because the operator is changing. That's because not every condition option is available for every operator. If you choose a Reactor-defined capability and attribute, it will recognize the operator's required type (so things like is TRUE and is FALSE will be allowed for attributes known to be boolean). When you use any extended attribute, like
x_vera_anything.anything(thex_verapart being the clue that's an extended capability and attribute), that system's native type governs, and for Vera, that's a string, so is TRUE and is FALSE don't apply.General recommendation is don't use the extended attributes when a Reactor-defined attribute is available.
To look beyond this, you'd need to post the attribute list for the device for starters. There's a Copy Attributes button in the entity detail. Use that, and paste the output here.
@toggledbits said in This trigger no longer working - complaining about the operator needing changing:
When you use any extended attribute, like x_vera_anything.anything (the x_vera part being the clue that's an extended capability and attribute), that system's native type governs, and for Vera, that's a string, so is TRUE and is FALSE don't apply.
Yes that's correct, I understand that is why I now need to use 1 or 0 instead of True or False etc.
-
x_vera_device.configured=true
x_vera_device.device_number=837
x_vera_device.device_type="urn:schemas-micasaverde-com:device:GenericIO:1"
x_vera_device.failed=null
x_vera_device.parent_device=1
x_vera_device.room_id="11"
x_vera_svc_micasaverde_com_HaDevice1.BatteryDate="1769544986"
x_vera_svc_micasaverde_com_HaDevice1.BatteryLevel="100"
x_vera_svc_micasaverde_com_HaDevice1.ChildrenSameRoom="1"
x_vera_svc_micasaverde_com_HaDevice1.Configured="1"
x_vera_svc_micasaverde_com_HaDevice1.EnableFlashControl="1"
x_vera_svc_micasaverde_com_HaDevice1.FirstConfigured="1769545001"
x_vera_svc_micasaverde_com_HaDevice1.LastUpdate="1769545001"
x_vera_svc_micasaverde_com_HaDevice1.ModeSetting="1:;2:A;3:;4:A"
x_vera_svc_micasaverde_com_HaDevice1.sl_Alarm="TAMPER_ALARM"
x_vera_svc_micasaverde_com_HaDevice1.sl_Alarm_updated=1769547652204
x_vera_svc_micasaverde_com_HaDevice1.sl_TamperAlarm="0"
x_vera_svc_micasaverde_com_HaDevice1.sl_TamperAlarm_updated=1769547682708
x_vera_svc_micasaverde_com_SecuritySensor1.Armed="0"
x_vera_svc_micasaverde_com_SecuritySensor1.ArmedTripped="0"
x_vera_svc_micasaverde_com_SecuritySensor1.IgnoreTripTime="2"
x_vera_svc_micasaverde_com_SecuritySensor1.LastTamper="1769547681"
x_vera_svc_micasaverde_com_SecuritySensor1.LastTrip="1769547681"
x_vera_svc_micasaverde_com_SecuritySensor1.Tripped="0"
x_vera_svc_micasaverde_com_ZWaveDevice1.AgiInfo="X"
x_vera_svc_micasaverde_com_ZWaveDevice1.AlarmType="0x7,"
x_vera_svc_micasaverde_com_ZWaveDevice1.AlarmVersion="0,1"
x_vera_svc_micasaverde_com_ZWaveDevice1.AssociationNum="5"
x_vera_svc_micasaverde_com_ZWaveDevice1.Capabilities="83,156,1,4,7,1,R,B,RS,|32S,34,48S:1,49:8,86,89,90S,94,112S,113S:5,114,115,122,128,132S:2,133S,134,142S,152,156S,"
x_vera_svc_micasaverde_com_ZWaveDevice1.ConfiguredAssoc=""
x_vera_svc_micasaverde_com_ZWaveDevice1.ConfiguredVariable="1-Motion detection sensitivity (8-255),1d,,6-Motion detection-alarm cancellation delay,2d,,24-Tamper operating modes (0-2),1d,,40-Illuminance report-threshold,2d,,42-Illuminance report-interval,2d,,60-Temperature report-threshold,2d,,62-Temperature measuring-interval,2d,,64-Temperature report-interval,2d,,66-Temperature offset,2d,"
x_vera_svc_micasaverde_com_ZWaveDevice1.ConfiguredWakeupInterval="7200"
x_vera_svc_micasaverde_com_ZWaveDevice1.FirmwareInfo="271,2065,12631"
x_vera_svc_micasaverde_com_ZWaveDevice1.LastReset="1769544953"
x_vera_svc_micasaverde_com_ZWaveDevice1.ManufacturerInfo="271,2049,4098"
x_vera_svc_micasaverde_com_ZWaveDevice1.NodeInfo="22,31,56,59,5e,72,73,7a,80,86,98,"
x_vera_svc_micasaverde_com_ZWaveDevice1.PlusInfo="1,6,0,12,7,12,7"
x_vera_svc_micasaverde_com_ZWaveDevice1.SecurityFailed="0"
x_vera_svc_micasaverde_com_ZWaveDevice1.SensorMlType="1,3,25"
x_vera_svc_micasaverde_com_ZWaveDevice1.SubscribedAlarms=",0x7,"
x_vera_svc_micasaverde_com_ZWaveDevice1.VariablesGet="1,15,6,30,24,0,40,200,42,3600,60,10,62,900,64,0,66,0,"
x_vera_svc_micasaverde_com_ZWaveDevice1.VariablesSet="1-Motion detection sensitivity (8-255),1d,,6-Motion detection-alarm cancellation delay,2d,,24-Tamper operating modes (0-2),1d,,40-Illuminance report-threshold,2d,,42-Illuminance report-interval,2d,,60-Temperature report-threshold,2d,,62-Temperature measuring-interval,2d,,64-Temperature report-interval,2d,,66-Temperature offset,2d,"
x_vera_svc_micasaverde_com_ZWaveDevice1.VersionInfo="3,4,24,3,3"
x_vera_svc_micasaverde_com_ZWaveDevice1.WakeupCapabilities="1,65535,7200,1"
x_vera_svc_micasaverde_com_ZWaveDevice1.WakeupInterval="7200"
zwave_device.capabilities="83,156,1,4,7,1,R,B,RS,|32S,34,48S:1,49:8,86,89,90S,94,112S,113S:5,114,115,122,128,132S:2,133S,134,142S,152,156S,"
zwave_device.failed=null
zwave_device.manufacturer_info="271,2049,4098"
zwave_device.node_id=162
zwave_device.version_info="3,4,24,3,3" -
I would delete the entity (using the delete button in the entity detail display), and the restart Reactor and see if it re-creates the Reactor-defined capabilities and attributes.
If not, look at the
reactor.logfile and see if it logged any errors related to VeraController. -
Well I've fixed the Trigger now. It was my fault I misunderstood what the popup was telling me. It was telling me it was gonna get rid of "is True" and blank that out, which is fine and as you said.
I thought it meant it was going to remove some other "Conditions" further down in the rule as I said.
Thanks
-
I would delete the entity (using the delete button in the entity detail display), and the restart Reactor and see if it re-creates the Reactor-defined capabilities and attributes.
If not, look at the
reactor.logfile and see if it logged any errors related to VeraController.@toggledbits said in This trigger no longer working - complaining about the operator needing changing:
I would delete the entity (using the delete button in the entity detail display), and the restart Reactor and see if it re-creates the Reactor-defined capabilities and attributes.
OK let me see if I can do that. You mean pressing the X here ? And then adding it back in to the trigger right?
-
@toggledbits said in This trigger no longer working - complaining about the operator needing changing:
I would delete the entity (using the delete button in the entity detail display), and the restart Reactor and see if it re-creates the Reactor-defined capabilities and attributes.
OK let me see if I can do that. You mean pressing the X here ? And then adding it back in to the trigger right?
@cw-kid said in This trigger no longer working - complaining about the operator needing changing:
OK let me see if I can do that. You mean pressing the X here ? And then adding it back in to the trigger right?
No... Entities page... where you got the Copy Attributes output. There's a delete button there.
Delete the entity, then restart Reactor. It will come back, hopefully with
binary_sensorcapability. -
After Delete / Restart:
arming.state=false
battery_power.alert_level=0.5
battery_power.level=1
battery_power.since=1769544986000
binary_sensor.state=false
motion_sensor.state=false
x_vera_device.configured=true
x_vera_device.device_number=837
x_vera_device.device_type="urn:schemas-micasaverde-com:device:MotionSensor:1"
x_vera_device.failed=null
x_vera_device.parent_device=1
x_vera_svc_micasaverde_com_HaDevice1.BatteryDate="1769544986"
x_vera_svc_micasaverde_com_HaDevice1.BatteryLevel="100"
x_vera_svc_micasaverde_com_HaDevice1.ChildrenSameRoom="1"
x_vera_svc_micasaverde_com_HaDevice1.Configured="1"
x_vera_svc_micasaverde_com_HaDevice1.EnableFlashControl="1"
x_vera_svc_micasaverde_com_HaDevice1.FirstConfigured="1769545001"
x_vera_svc_micasaverde_com_HaDevice1.LastUpdate="1769545001"
x_vera_svc_micasaverde_com_HaDevice1.ModeSetting="1:;2:A;3:;4:A"
x_vera_svc_micasaverde_com_HaDevice1.sl_Alarm="TAMPER_ALARM"
x_vera_svc_micasaverde_com_HaDevice1.sl_TamperAlarm="0"
x_vera_svc_micasaverde_com_SecuritySensor1.Armed="0"
x_vera_svc_micasaverde_com_SecuritySensor1.ArmedTripped="0"
x_vera_svc_micasaverde_com_SecuritySensor1.IgnoreTripTime="2"
x_vera_svc_micasaverde_com_SecuritySensor1.LastTamper="1769547681"
x_vera_svc_micasaverde_com_SecuritySensor1.LastTrip="1769547681"
x_vera_svc_micasaverde_com_SecuritySensor1.Tripped="0"
x_vera_svc_micasaverde_com_ZWaveDevice1.AgiInfo="X"
x_vera_svc_micasaverde_com_ZWaveDevice1.AlarmType="0x7,"
x_vera_svc_micasaverde_com_ZWaveDevice1.AlarmVersion="0,1"
x_vera_svc_micasaverde_com_ZWaveDevice1.AssociationNum="5"
x_vera_svc_micasaverde_com_ZWaveDevice1.Capabilities="83,156,1,4,7,1,R,B,RS,|32S,34,48S:1,49:8,86,89,90S,94,112S,113S:5,114,115,122,128,132S:2,133S,134,142S,152,156S,"
x_vera_svc_micasaverde_com_ZWaveDevice1.ConfiguredAssoc=""
x_vera_svc_micasaverde_com_ZWaveDevice1.ConfiguredVariable="1-Motion detection sensitivity (8-255),1d,,6-Motion detection-alarm cancellation delay,2d,,24-Tamper operating modes (0-2),1d,,40-Illuminance report-threshold,2d,,42-Illuminance report-interval,2d,,60-Temperature report-threshold,2d,,62-Temperature measuring-interval,2d,,64-Temperature report-interval,2d,,66-Temperature offset,2d,"
x_vera_svc_micasaverde_com_ZWaveDevice1.ConfiguredWakeupInterval="7200"
x_vera_svc_micasaverde_com_ZWaveDevice1.FirmwareInfo="271,2065,12631"
x_vera_svc_micasaverde_com_ZWaveDevice1.LastReset="1769544953"
x_vera_svc_micasaverde_com_ZWaveDevice1.ManufacturerInfo="271,2049,4098"
x_vera_svc_micasaverde_com_ZWaveDevice1.NodeInfo="22,31,56,59,5e,72,73,7a,80,86,98,"
x_vera_svc_micasaverde_com_ZWaveDevice1.PlusInfo="1,6,0,12,7,12,7"
x_vera_svc_micasaverde_com_ZWaveDevice1.SecurityFailed="0"
x_vera_svc_micasaverde_com_ZWaveDevice1.SensorMlType="1,3,25"
x_vera_svc_micasaverde_com_ZWaveDevice1.SubscribedAlarms=",0x7,"
x_vera_svc_micasaverde_com_ZWaveDevice1.VariablesGet="1,15,6,30,24,0,40,200,42,3600,60,10,62,900,64,0,66,0,"
x_vera_svc_micasaverde_com_ZWaveDevice1.VariablesSet="1-Motion detection sensitivity (8-255),1d,,6-Motion detection-alarm cancellation delay,2d,,24-Tamper operating modes (0-2),1d,,40-Illuminance report-threshold,2d,,42-Illuminance report-interval,2d,,60-Temperature report-threshold,2d,,62-Temperature measuring-interval,2d,,64-Temperature report-interval,2d,,66-Temperature offset,2d,"
x_vera_svc_micasaverde_com_ZWaveDevice1.VersionInfo="3,4,24,3,3"
x_vera_svc_micasaverde_com_ZWaveDevice1.WakeupCapabilities="1,65535,7200,1"
x_vera_svc_micasaverde_com_ZWaveDevice1.WakeupInterval="7200"
zwave_device.capabilities="83,156,1,4,7,1,R,B,RS,|32S,34,48S:1,49:8,86,89,90S,94,112S,113S:5,114,115,122,128,132S:2,133S,134,142S,152,156S,"
zwave_device.failed=null
zwave_device.manufacturer_info="271,2049,4098"
zwave_device.node_id=162
zwave_device.version_info="3,4,24,3,3" -
OK. That's easy to address.
- Stop Reactor
- Delete the entire
storage/entitiessubdirectory (no others, just that one) - Restart Reactor
This will force all Controller-based entities to be rebuilt, like the motion sensor was, just in bulk.
-
OK I might have to do it on bulk then as you say.
I've been looking at some old rules that I have not touched or done anything with or messed with those devices at all, those rules seem fine and still have the binary_sensor.state attribute etc.
But I am sure for "new" devices I have paired back to the Vera hub today and then had to correct / edit those rules or create new rules, them ones only showed me the extended attributes only in that menu.
These are some other "new" devices paired / added today to the Vera hub and their rules / triggers.
- This is the Site Sensor plugin new today on Vera, it only has extended attributes (Maybe expected for that as its a virtual device?)
- Another motion sensor I paired today a Hank one. That also has no Reactor defined Capability / Attribute, there was only extended attributes available in the menu.
- This one did work, a Hank door sensor, I paired yesterday, that one does have binary_sensor.state.
So it seems hit or miss if the new devices get them or not.
I will double check what happens? When I paired more new devices soon.
Thanks.
