Neo coolcam z-wave devices

zwave
Tags: #<Tag:0x00007fe06632d130>

(Panos) #121

Thanks @inaftanaila !!! you spotted it! The device is recognised fine now. One small issue. I don’t see battery levels showing. Do you also see a dash on the site map ?


(ionel) #122

Give it a bit - after some close/opens, mine started to show up. I see actual values for battery levels (in PaperUI as I did not care enough to add that to a sitemap).


(Daniel) #123

Yeah, thanks @inaftanaila! A triple click and the motion sensor wasn’t an unknown device in the Paper UI inbox any longer. (I didn’t have to exclude or include it over again).

@leijona Item values might take some time. However, a single click made the battery value appear in the HABPanel.

(I also tried 2 power plugs from Shenzen Neo and they got recognised right away).


(IZ) #124

@Lida, @inaftanaila, @leijona, which z-wave controller hardware do you have? I’m suspecting that my UZB1 ME stick is faulty.


(Daniel) #125

@engy I’m using an Aeotec Z-stick Gen 5


(ionel) #126

Same as @Lida… Aeotec z-stick gen 5…


(Panos) #127

@engy I am using the same stick like you.


(Piotr "Rook") #128

Hello

I have a few Neo CoolCam power plugs. One of the is unrecognised and in node.xml I can see:

     <nodeId>12</nodeId> 
      <version>4</version>
      <manufacturer>0x258</manufacturer>
      <deviceId>0x1483</deviceId>
      <deviceType>0x3</deviceType>
      <listening>true</listening>
      <frequentlyListening>false</frequentlyListening>
      <routing>true</routing>
      <security>false</security>
      <beaming>true</beaming>
      <maxBaudRate>40000</maxBaudRate>

In my opinion it is exactly the same thing-type id=“shenzhen_powerplug_00_000” with


 <property name="vendor">Shenzhen Neo Electronics Co., Ltd</property>
      <property name="modelId">Power Plug</property>
      <property name="manufacturerId">0258</property>
      <property name="manufacturerRef">0003:0087,0003:1087</property>
      <property name="dbReference">397</property>
      <property name="defaultAssociations">1</property>
    </properties>

Can you add it or should I try playing with DB @chris?

Cheers,
Piotr “e-rook”


(Chris Jackson) #129

I’ve added the IDs to the database and will update the binding in a day or so. If you have any issues with the initialisation then please report back - just in case the device isn’t quite the same as the one in the database…


(Marcel) #130

Hi community
Do you see the lumiance and the temperature of neo PIR. I see the motion, alarm and battery, but not lumiance and temperature … this values are everytime zero :flushed:


(Piotr "Rook") #131

I have similar problem but I blame Neo PIR. Earlier I used smarthome from razberry and luminance reports where dying after some time. Temperature - always failed… sometimes I am temped to check if there is any temperature sensor inside :wink:


(Martin van Wingerden) #132

I have a temperature and luminance, but by default the change has to very high for it to report to me it feels like a software weakness that if it becomes dark or light slowly it will never trigger. Pointing a decent flashlight one it did trigger it in my case.

Also note that only certain series have the build in temperature sensors, I have 2 without them and one with them, and it works.


(Piotr "Rook") #133

Thanks, seems I am impatient with this sensor and I have only one :wink: from doc it seems it should support temperature but it does not.

This PIR is not yet critical on my installation path but I will focus more on it if you have succeeded :grinning:


(IZ) #134

My all problems were solved and sensors connected successfully immediately after USB stick swap from UZB1 to Aeotec Z-stick Gen 5. It seems I received a faulty UZB1 device, and wasted so much time. :expressionless:


(Holger OpenhabUser) #135

Zwave is always a mystery :slight_smile: I am also now happy that everything is working, but for future extensinon I will use more Sonoff devices with MQTT, this is easier.


(IZ) #136

@chris, @martinvw. is it possible to fetch lastUpdate info for Neo devices?

Tried the following configs and non of these are working:

DateTime cCamPirLastUpdated "CCam PIR last updated [%1$tY.%1$tm.%1$td %1$tH:%1$tM]" { zwave="7:command=info,item=LAST_UPDATE" }
DateTime cCamPirLastUpdated1 "CCam PIR last updated [%1$tY.%1$tm.%1$td %1$tH:%1$tM]" { channel="zwave:device:controller:node7:LAST_UPDATE" }

Thank you in advance.


(Chris Jackson) #137

It looks like you are using OH1 definitions? I don’t think there’s a channel called “LAST_UPDATE” in OH2, so this won’t work.


(IZ) #138

@chris, so that means the only way to get lastUpdate of zwave node is via rules. Right?


(vossivossi) #139

I must admit I did not know that a channel for “LAST_UPDATE” existed in OH1 ( I used OH1 just or first testing, not for real production environment).
However, if the channel existed, WHY does it not exist anymore in OH2? The only solutions to get a last update timestamp by rules is either to pile up hundred of lines of Spagetthi code for each item (very ugly and hard to maintain) or to experiment around with group based persistence (but which only gives you 99,8% reliability).
So WHY in the world this regression?


(Chris Jackson) #140

I’m not 100% sure - there has been a lot of discussion about this on the list, but probably nothing has been added yet and rules is the only way.

OH2 is not the same as OH1 - for starters, OH1 didn’t even have the concept of “channels”.

This issue has been discussed on the list a few times. Yes, I could provide a mechanism to give the last update time of a channel, and the KNX binding could provide another similar mechanism, and the weather binding another similar mechanism, but for me this is not something the binding should be doing. The binding is there to provide the interface to the hardware - the system should provide features that are generic, such as the last update time of a channel (IMO).

It’s not a regression - OH2 binding is quite different to OH1. The concepts for bindings are very different than OH1. Concepts in general from ESH are in many cases different.

Also remember that filling up every binding with spaghetti code is also not nice - right? Adding lots of channels into the binding is just as messy - only now it’s a mess that the users don’t have to see, but it’s still there.

Don’t get me wrong - I agree that this is a useful feature. But IMO features should go in the “right” place, and commonly used features should be in a common place - not reimplemented lots of times in every binding.