Connection to Domoticz defined devices like Blinds and On/Off switches

Something strange going on with contact in DZ, it reacts differently than switch or motion on On/Off. I have used another command to test this, could you update from repo and check if OK?

For notifications I removed the setting of these for sensor types, the reasoning being that only states need to be transferred to DZ and not back, as the original is within ST. Notifications are set for Switch/Light/Lock as these can be acted upon in DZ as well, Agree?

That change did the trick for the contact.

Seems logical, should the notifications on sensors clear? I am still seeing it set on the ST to DZ temp sensor. Should I just manually set the problem sensors, the ones missing the notification settings, or did you want me to hold of to test?

Thanks,
Wob

Keep them for the test. When I have a chance later today and habe checked
the state I will know if it makes sense.

1 Like

Committed 6.15. I have added a setting in the domoticz room selection part of the App that, if selected, will delete devices in ST when they are not part of any selected room anymore. When a device is removed from the app state also the notifications will be cleared in the DZ device. Have a go, any issues (there will be, i had this code running for a day now) please!

1 Like

Notifications seem backwards for me, it’s setting notifications on devices outside my synced room and clearing on devices inside the room.

I uninstalled the smartapp and manually cleared all notifications, then reinstated, same thing happened.

I am also seeing the unknown devices ST to DZ issue again.

Edit: dust has settled from the reinstall, switches seem ok, but the temp sensors are backwards, notifications set for devices outside scope and not set for devices inside scope, all DZ to ST devices.

Also seems to include thermostat and pressure devices.

Wob

Yes. I have seen some issues as well today. My setup is all inclusive. Was
hard to define all into room plan without Major disruption. Will do added
testing tomorrow.

Thx for your help

met vriendelijke groeten,

Martin

1 Like

I had an idea on those missing events for sensors in DZ, what is your update time for sensors in the settings of DZ?
I noticed in my DZ devIce log that reporting was done only on that interval.

Do you mean under notifications? I can adjust down, but I have waited overnight before. Also been about 12 hours since my last tweak, still no notifications set on temp sensors.

Notification Intervals:
Sensors: 2 hours
Switches: direct

I think found the reason for Temp notifications not being set. I am checking for Temp as a specific type, but also temp+humidity and temp+hum+pressure exists. Changed this,

As far as notifications for sensors, i am currently setting them for all that i can find in DZ. When they report back to the app, i just ditch the messages for those that does not matter in the App. The difference in scope you see, might be a side effect from the above, as I did not set the notifications for sensor that where of type temp+humidity and temp+hum+pressure, which i noticed was the case in one of the devices you gave the info for. I am now setting all sensors notifications. I will check in the next release for usage of the sensors idx in the app and only set notifications for those.

Also with 6.16 initial seed of value for virtual devices

V6.16 Fix for multipurpose temp/hum/pressure sensors to be recognized for notifications
Do intitial seed of values for virtual devices in DZ from ST when devices are created

Nice work, I am now seeing notifications set on my temp\humidity sensors, I am also seeing incoming temp\humidity readings now.

I still have 2 device types missing notifications, these are DZ ot ST devices.

Thermostat and Pressure Sensor. I am really not too concerned about the later as pressure offers very little value in my climate, but just highlighting. Also of note, the pressure sensor comes from a single temp\humidity\pressure device, but DZ doesn’t have a single device type, it splits them to temp\humidity and a seperate pressure sensors. I’ll link the json data for both bellow.

Out of interest, Is there a reason for different approaches to notifications on sensors compared to switches? I noticed switch notifications are only set on devices inside my room scope.

Also a future tweak request, it would be nice if the outgoing ST to DZ temp and humidity could be grouped to single DZ device, rather than 2 device, maybe merge if the name is the same?

Thanks again, I’ll continue to monitor and report back how my system goes over a few days.

Thermostat

{
   "ActTime" : 1518387395,
   "AstrTwilightEnd" : "21:17",
   "AstrTwilightStart" : "04:58",
   "CivTwilightEnd" : "20:14",
   "CivTwilightStart" : "06:02",
   "DayLength" : "13:21",
   "NautTwilightEnd" : "20:45",
   "NautTwilightStart" : "05:31",
   "ServerTime" : "2018-02-12 09:16:35",
   "SunAtSouth" : "13:05",
   "Sunrise" : "06:27",
   "Sunset" : "19:48",
   "result" : [
      {
         "AddjMulti" : 1.0,
         "AddjMulti2" : 1.0,
         "AddjValue" : 0.0,
         "AddjValue2" : 0.0,
         "BatteryLevel" : 255,
         "CustomImage" : 0,
         "Data" : "25.0",
         "Description" : "GoogleHome: (the )?(AC|(Air( )?(Con)?(ditioner)?)) (set)?( )?(thermostat|temp)",
         "Favorite" : 1,
         "HardwareID" : 7,
         "HardwareName" : "Mitsubishi AC",
         "HardwareType" : "Dummy (Does nothing, use for virtual switches only)",
         "HardwareTypeVal" : 15,
         "HaveTimeout" : false,
         "ID" : "0014073",
         "LastUpdate" : "2018-02-12 09:16:17",
         "Name" : "AC Thermostat",
         "Notifications" : "false",
         "PlanID" : "2",
         "PlanIDs" : [ 2, 23, 28 ],
         "Protected" : false,
         "SetPoint" : "25.0",
         "ShowNotifications" : true,
         "SignalLevel" : "-",
         "SubType" : "SetPoint",
         "Timers" : "false",
         "Type" : "Thermostat",
         "TypeImg" : "override_mini",
         "Unit" : 1,
         "Used" : 1,
         "XOffset" : "307",
         "YOffset" : "345",
         "idx" : "35"
      }
   ],
   "status" : "OK",
   "title" : "Devices"
}

Pressure Sensor

{
   "ActTime" : 1518387427,
   "AstrTwilightEnd" : "21:17",
   "AstrTwilightStart" : "04:58",
   "CivTwilightEnd" : "20:14",
   "CivTwilightStart" : "06:02",
   "DayLength" : "13:21",
   "NautTwilightEnd" : "20:45",
   "NautTwilightStart" : "05:31",
   "ServerTime" : "2018-02-12 09:17:07",
   "SunAtSouth" : "13:05",
   "Sunrise" : "06:27",
   "Sunset" : "19:48",
   "result" : [
      {
         "AddjMulti" : 1.0,
         "AddjMulti2" : 1.0,
         "AddjValue" : 0.0,
         "AddjValue2" : 0.0,
         "BatteryLevel" : 255,
         "CustomImage" : 0,
         "Data" : "1001.0 Bar",
         "Description" : "",
         "Favorite" : 0,
         "HardwareID" : 3,
         "HardwareName" : "Mi Gateway",
         "HardwareType" : "Xiaomi Gateway",
         "HardwareTypeVal" : 95,
         "HaveTimeout" : false,
         "ID" : "B7E40801",
         "LastUpdate" : "2018-02-12 09:16:07",
         "Name" : "Outside Pressure",
         "Notifications" : "false",
         "PlanID" : "19",
         "PlanIDs" : [ 19, 28 ],
         "Pressure" : 1001.0,
         "Protected" : false,
         "ShowNotifications" : true,
         "SignalLevel" : "-",
         "SubType" : "Pressure",
         "Timers" : "false",
         "Type" : "General",
         "TypeImg" : "gauge",
         "Unit" : 1,
         "Used" : 1,
         "XOffset" : "219",
         "YOffset" : "68",
         "idx" : "190"
      }
   ],
   "status" : "OK",
   "title" : "Devices"
}

The reason for different approach is that sensors could be assigned used
everywhere and assigned to a lot of things. I will narrow it down, but it
did not make sense at the time.

Pressure is a capability that is not standard in ST, so I was holding off
on implementing. Thermostat can be defined in ST, you did select them as a
type?

Ahh ok, as I mentioned not too fussed on pressure, for some reason I thought it was in you list.

I checked all device types, the Thermostat shows in the list installed devices, and in my things, but no notifications and as such if I change it, the change flows to DZ but nothing changes is ST.

Fixed in 6.17.

1 Like

Hello Martin,

your fix is still working fine with the standard automations. But as I’m trying to use CoRE, the exact same problem appeared again (multiple // “Turn on” on a series of blinds lead to all blinds going down, then stopping partially closed).

Anyway, thanks for all the amazing work!!!

Regards

You are sure you are not performing a second “on” to the same blind, that might act as a stop for certain brands.

Does CoRE support the windowShade capability? I am in the process of redoing the blinds with this capability, and splitting out some of the visible attributes to a component device for use with another app called smartscreens.

Martin,

Only one “on” per blind.
I just changed “turn on” to “close” and had no issues with time (2 out of 2 tests successful 
). I can see Close/Open/Pool/Refresh/Set level/Stop/Turn off/Turn on as available device actions. I selected “lights/relay/switches” as a device type for this CoRE Piston.
Yes, a type “window shade” do exist in CoRE.

Regards

Will be releasing new device handler for blinds somewhere this week. It has the windowShade capability, it also will have a cleaner interface when the Smart Screens app is not used. It will only define the additional tiles when this app is being used.

that did the trick.

Thanks. While the “close” action works fine if I trigger it manually through piston simulation, the problem still occurs when the piston condition is reached
 I look forward testing your windowShade implementation :slight_smile:

You can try it out, make sure you have latest of domoticz Server, domoticzBlinds and to be sure child composite device domoticzBlindsSmart.