v7.4 for me.
And @aumatt - regarding Zone Seal State (P199E 6E) - I definitely have that (and all other P199E options) enabled …
v7.4 for me.
And @aumatt - regarding Zone Seal State (P199E 6E) - I definitely have that (and all other P199E options) enabled …
Here’s my logs right before it stops decoding.
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/nessclient/client.py", line 141, in keepalive
self._update_loop(),
File "/usr/local/lib/python3.6/site-packages/nessclient/client.py", line 119, in _recv_loop
event = BaseEvent.decode(pkt)
File "/usr/local/lib/python3.6/site-packages/nessclient/event.py", line 39, in decode
return StatusUpdate.decode(packet)
File "/usr/local/lib/python3.6/site-packages/nessclient/event.py", line 147, in decode
request_id = StatusUpdate.RequestID(int(packet.data[0:2], 16))
File "/usr/local/lib/python3.6/enum.py", line 291, in __call__
return cls.__new__(cls, value)
File "/usr/local/lib/python3.6/enum.py", line 533, in __new__
return cls._missing_(value)
File "/usr/local/lib/python3.6/enum.py", line 546, in _missing_
raise ValueError("%r is not a valid %s" % (value, cls.__name__))
ValueError: 23 is not a valid RequestID
Then it’s the same three lines repeated.
2019-02-08 16:53:32 DEBUG (MainThread) [nessclient.client] Forcing a keepalive state update
2019-02-08 16:53:32 DEBUG (MainThread) [nessclient.client] Closing stale connection and reconnecting
2019-02-08 16:53:32 DEBUG (MainThread) [nessclient.client] Attempting to connect
I have got all the parts and have hooked mine up. HASS is showing connected to the module but when I telnet into it I only am seeing the following string output over and over again regardless of which zoine is tripped
8300360S00E9
Is this actually HASS asking for a status update? If so it doesnt appear I am seeing any info from the board?
Have you got all the P199E options enabled?
Yes I am wondering if my cable I bought isn’t wired up correctly. Looking at the Austech forum I see there were discussions about whether some of these serial cables weren’t correct. Can you confirm what each pin is starting from the side where the telephone jack is? Is it GND - TX - RX ? My plug isn’t wired like that?
Thanks Matt. I swapped all the wires around and that has it working.
However now I am getting a crash due to “Unable to consume all data” due to this sequence “8300360S14E48300360S00E98300360S00E987008361000600190216204117e6” which looks like it is maybe an echo from HASSIO requesting three status updates and then a properly formed response.
Is anyone else seeing this? If not and if you are using a USR-TCP232-302 can you tell me what your settings are on the Serial Port page? I have tried setting LINK off and also “Similar RFC2217” but that didnt make any difference?
Edit: I wonder if the packet was sent with a CR on the end if that would help?
Hi @OzGav
I’ve got 9600,8,N,1 and then LINK and ‘Similar RFC2217’ set on my USR-TCP232
A bit of a development on my side - I upgraded from ResinOS to HassOS this morning - along with an upgrade from 0.87 to 0.87.1 and I haven’t been able to get stable NESS since!
Some more digging to be done …
I havent got time for a few days but I am thinking of adding to client.py the following on line 117
if len(decoded_data) > 28: decoded_data = decoded_data[-28:]
This would strip off the actual data I need from my spurious extra long data!
Hi all,
Sorry for the delay since I last posted. I found a small amount of time this morning and have raised a handful of pull requests to hopefully make the client library more stable:
I found that the documentation provided by Ness is inconsistent with regard to the endianness of the data returned for a few of the user interface responses. The fixes should improve the following:
I have released version 0.9.10
of the nessclient
library, perhaps a handful of you all here can give it a try and let me know how it goes. If successful, I’ll raise a PR in home-assistant to upgrade to this version
I can just copy 0.9.10 into a ness_alam directory that I create under custom components can’t I? That will override the current version?
I am unsure if that would work. I think you will need to pip install
it from within the home-assistant virtual environment (if one exists).
pip install --upgrade [email protected]
Might be a bit more complicated if you are running inside docker though.
Hmmm… Thought it would https://developers.home-assistant.io/docs/en/creating_component_loading.html
I am using some other custom components and all of those have either a setup or setup_platform function but yours doesn’t and thus I am getting this error:
019-02-21 11:51:24 ERROR (MainThread) [homeassistant.setup] Error during setup of component ness_alarm
Traceback (most recent call last):
File “/usr/local/lib/python3.6/site-packages/homeassistant/setup.py”, line 148, in _async_setup_component
component.setup, hass, processed_config) # type: ignore
AttributeError: module ‘custom_components.ness_alarm’ has no attribute ‘setup’
So I might have to wait until you roll that into an update because I don’t think I can install anything outside of the config directory. This is unfortunate because I was hoping to be able to easily modify the code to solve the problem I am having with multiple messages being returned all joined together.
@nickw444 Thank you for your continued support of the Ness component. I’ve updated to 0.9.10 even though I’ve been quite stable any improvements are welcome.
I’m more concerned with the lack of responsiveness in the sensors detecting motion and the state in HA changing. Do you think you could look into this next? I’m currently only using the component to arm/disarm the alarm due to the sensor delays.
Interesting. You are using the Ness IP232 and don’t have this run together message problem but arent getting the responses quickly. I get an instant response to a zone tripping but it comes back with a long message which crashes the routine. I feel this is solvable!
BTW are you running on a Raspberry PI? If so how did you update?
I agree!
It’s been suggested before that the delay seems to be caused due to it only sending zone states when it polls, would be interested to hear @nickw444 thoughts on this.
Regarding your question I’m running HA in a python virtual environment, so while active in the environment just issued pip3 install --upgrade nessclient
Sorry if we have already covered this off - @cryptelli; when you have debug logging on as suggested by Nick, do you see messages coming from your NESS? If not, it might be worth connecting directly to NESS serial port (e.g via putty) and confirming if you get messages on zone changes?
If you are seeing messages delayed when connected via putty then that sounds to me like there is an issue with the IP232