Values are not getting updated in HomeAssistant

[CV-Private]

I've been able to successfully install the Bepacom-BACnet-IP-Installation. It found my GTW-21 BACnet device from the heatpump manufacturer Brötje (BDR Thermea Group). It is a BACnet certified device, to which I can connect with YABE normally.

I'm able to see the Present Values in the HomeAssistant Entities.

However, the values are not getting updated at all. It look like they have been read once, and now they're frozen forever. This is what I see in HA. It would be expected, though, that the temperature value would change very dynamically over time.

What did I miss to configure? Any help would be much appreciated! Best regards, Christian

[Bepacom-Raalte]

The add-on is separate from the integration. The add-on has it's own version number. The integration has to be installed from HACS like you did, then restart Home Assistant. It should work then. I did put out a new beta v0.1.6b4, so please download that one.

[CV-Private]

The NoneType error is back again.

I'm assuming that v0.1.6b4 is running now. Is there any way for confirming the version number?

[Bepacom-Raalte]

I think it's likely you're on the right version. To confirm, you can look at HACS, or compare the code.

If under custom_components/bacnet_interface/coordinator.py in the _use_websocket function is the following function exactly the same, you're in the latest version:

Could you share the Home Assistant logs for the integration? I don't need the add-on logs at the moment.

[CV-Private]

Ok, then I can confirm that v0.1.6b4 is currently running.

Where do I find those Home Assistant logs that you need? Here's the log downloaded from the Add-On, in case that it helps:

bacnet_addon_logs_2024-03-20.zip

[Bepacom-Raalte]

In Home Assistant > Settings > System > Logs, there will probably be a bunch of errors with tracelogs. Those are the ones I want.

[CV-Private]

Here's the log file:

home-assistant_2024-03-20T15-09-46.634Z.zip

[GravySeal]

I think there's a combination of problems happening. First is that maybe through the websocket, the updates come too fast for Home Assistant to handle. In the add-on 1.4.0b1 I set the delay to 1 second per message. In the add-on configuration, please set the "Update interval" option to at least 60 for now too. CoV can still be disabled at first.

Second is, the integration asks the add-on too soon for data. While the add-on is still busy reading, the integration will get the data in the form of an incomplete json file. What you can try after the add-on completed reading is:

Go to the integration page. There, you can select in the options the option to reload the integration.

If you want to be sure you have the correct version, you can always redownload the integration through HACS.

[CV-Private]

With add-on 1.4.0b1 (version confirmed and HA rebootet), I'm still getting the NoneType error. Current settings: Update-Interval: 300s, no CoV subscriptions. Here's the system log:

home-assistant_2024-03-21T11-10-59.516Z.log

[GravySeal]

Could you maybe export an EDE file of your device in Yabe? I'm curious if anything is missing in the previous json file.

[CV-Private]

The EDE export from Yabe is quite strange with almost no data inside: Device1_EDE_EDE.csv

The Yabe-Map file has the full device information, though: GTW-21.zip

Here's the EDE file that was provided by the manufacturer BDR-Thermea, together with the GTW-21 hardware: FG040D_X_00_EDE R1.2.1.csv

[GravySeal]

Unfortunately nothing comes up in Yabe when I try to open the YabeMap file. Maybe I'm using it wrong? The Yabe EDE is indeed empty, but the BDR EDE file seems complete.

[CV-Private]

I'm not familiar enough with the Yabe files and their purpose. Maybe the map is just a database with object and property names that is useful when the program is connected to the device, but I not sure... I hope you can find what you need in the BDR EDE file.

[GravySeal]

Could you check for updates and then install version 1.4.0b2? I added some checks for the websocket. If it goes wrong in there, it should show in the logs.

[CV-Private]

Here's a HA system log with 1.4.0b2. Ignore the Modbus errors - that device is off. I hope you can still work with the log. home-assistant_2024-03-22T22-56-38.826Z.log

[GravySeal]

Could you also give me the addon logs?

[CV-Private]

Here they are: bacnet_addon_logs_2023-03-23.txt

I don't see much news in the log. The Who Is requests came from my Node-Red, which I had On for some experiments last night, but I turned it off later.

By the way: I noticed that the switch for turning the logging On/Off is no longer in the Configuration window, and no files are being stored in the Shared folder. Is that expected?

[CV-Private]

The error that occurs most frequently is the one shown below. It occurred 531 times since I installed v1.4.0b2 last night.

It also occurs when I do nothing. Since I installed v1.4.0b2, I only changed the AV_1688 Setpoint like 4 times.

I guess that this error is related to some automatic refreshing that the Add-On is trying to do. It seems to occur every minute - not an interval that I have set anywhere.

[CV-Private]

The NoneType error that is related to my manual actions (changing the AV_1688 Setpoint) is probably this one:

[CV-Private]

On another note: I turned the Debug logging On this morning, but I don't know what effect that has and where to find the Debug log. Should I have it On or Off?

[GravySeal]

The switch for exporting is indeed gone. I limited the filesize and only made them downloadable through the add-on. The logs are reset after each add-on reboot, so there's no data lingering in Home Assistant itself.

I just pushed update 1.4.0b3, with some nginx security disabled. If you want, please download a websocket client for your browser (Websocket Weasel for Firefox or Simple Websocket Client for Chrome).

The websocket endpoint from the add-on will be reachable through the websocket client. The link for the add-on websocket will be like: ws://x.x.x.x:8099/ws where x.x.x.x is your Home Assistant IP address.

On each update, the websocket should push the entire json file to your browser. Could you share the results? And if it's not giving any data, please let me know too.

The debug function in the integration will give slightly more data, and will give you a downloadable file when you stop the debug logging again.

[CV-Private]

Some interim finding: after updating to 1.4.0b3 (and HA restart), I'm seeing that the entity has no value in the temperature field:

Clicking on the entity shows that it is no longer be made available by the Integration bacnet_interface:

I've seen this before after previous updates. I can resolve it by deleting and reinstalling the Integration, but it's annoying. Any hints how to prevent that problem?

Here's the Debug log from the integration: home-assistant_bacnet_interface_2024-03-23T14-34-34.848Z.log

[CV-Private]

I reinstalled the Integration, but I'm not getting any data in the Websocket Weasel. Prior to that screenshot, I changed the AV_1688 Setpoint several times, firstly with success and later with NoneType errors:

Here's the Integration Debug log: home-assistant_bacnet_interface_2024-03-23T15-03-56.490Z.log

HA System log: home-assistant_2024-03-23T15-03-32.102Z.log

Add-on log: bacnet_addon_logs_2024-03-23b.txt

[GravySeal]

Unfortunately websockets can't be opened directly through the URL, you need to install the plugin I mentioned.

It should look something like this:

or:

[CV-Private]

Ok, got it! I tried various URLs, with and without wss://, with and without /ws, but I'm getting only errors, or messages like that:

[GravySeal]

Did you try ws://192.168.66.62:8099/ws as well? wss:// won't work as it's not secured that way.

[CV-Private]

That works! Here's the Weasel output, copied to a file: Weasel_2024-03-23.zip

[GravySeal]

So I've taken a look at the data being sent from the add-on, and it basically seems correct. Somewhere in the Integration is probably the problem, specifically in the websocket receiving data. I have a feeling Home Assistant doesn't handle an exception somewhere in the code, resulting in the NoneType error.

To rule out the add-on, could you perhaps keep the websocket open for sometime and see if any strange or broken messages appear?

Thank you for being so cooperative!

[CV-Private]

Sure, you're most welcome! Thanks for your incredible support!

So, I just leave the Weasel open, watching its output without doing any actions in HA, right?

Nothing has changed in Weasel since I sent you the log.

[GravySeal]

Basically just leave it open yeah. Expected behaviour is whenever there's an update in your BACnet device it should send a new websocket message. In your case, it should only be when the update timer ran out and everything gets updated again.

I updated the integration again to v0.1.6b5, could you upgrade and see what happens then?

[CV-Private]

It seems you nailed it! Since I updated to v0.1.6b5, I didn't get any NoneType error anymore! :-) Also, there are no more errors related to BACnet in the HA system log.

Weasel is getting a new set of data whenever I change the AV_1688 value from HA. The Weasel plugin became unresponsive after a while and I had to close Firefox. It works again after restarting it.

However, I'm currently having an unidirectional control of the AV_1688 value. I can change the value in HA, it is accepted by the room controller and it's being shown in HA.

The other direction does NOT yet work; when I change the temperature on the room controller, then it's not getting updated in HA, even if I wait longer than the 300s update interval that I have currently set.

I have currently no CoV subscription active. I'm going to try that next.

[GravySeal]

Awesome! I'm glad it's working now. I found the issue was deeply hidden in the library I made for the integration. NoneType shouldn't be possible anymore (I hope)!

I will take a look at some things relating CoV. If you play around with those settings, please make some logs as well (in the add-on). Might be useful to figure something out for it.

[CV-Private]

Sounds good!

I'm doing tests with CoV subscription now. As long as a subscription is active, the HA value is getting updated, which is good. I'm trying now how long I can make the CoV subscription - I don't know what the maximum time could be, or if there's a way for subscribing permanently (what time value would I have to enter?). I didn't see in Yabe that a subscription would get terminated, but I haven't had Yabe running for a very long time, like weeks.

I do see, though, that the CoV subscription is not getting renewed by the Add-On upon expiry; I have to re-subscribe manually. If you could add a mechanism for auto-renewal to the Add-On, that would be great.

As a further improvement, I would suggest that the WebUI shows the actual subscription status. Currently, there's no status change visible when the subscription expires. It would also be nice to have a button in the WebUI for re-subscribing to an expired subscription, to eliminate the need for browsing the entire object tree again.

[GravySeal]

Currently the add-on automatically tries to subscribe the longest time supported by every BACnet device, which is 8 hours. Yabe resubscribes every 2 minutes, which is why it seems like an endless subscription. Some devices support indefinite subscriptions when using a lifetime of 0.

In the past I tried to manage every subscription in a task, but for some reason in certain devices the add-on got unresponsive. Might try to get something similar going again, but I'll have to find out how to optimize it that way first. This would also automatically resubscribe when the lifetime is over. Currently after automatically subscribing, the add-on resubscribes to every subscription made after 8 hours (which is 28799 seconds).

In Yabe, can you see the Active Cov Subscriptions property of your device? If Yabe can get it, it might reveal some useful info.

If you try enabling automatic CoV subscriptions now for one object type, analogInput for example, what happens? Could you share a log of this?

[CV-Private]

In this Yabe screenshot you can see the AV_1688 subscription 107s before it expired:

After expiry, it disappeared from the list.

A good improvement in v0.1.6b5 is also that the subscription is now indeed active for the whole duration of its lifetime. The above shown subscription lasted for 3600s. I just started one with 28800s. 0s lifetime doesn't make a permanent subscription, unfortunately.

I'm suspecting that in previous releases the subscription was terminated as soon as the Integration errors occurred. Therefore, the subscription didn't last longer than 60s, which was the time interval of one error type.

Subscribing for one object type will overload the GTW-21. It doesn't support so many subscriptions and will return errors. I don't know how many subscription it supports; it isn't mentioned in the manual.

[CV-Private]

This is how it looks like when I configure the subscription for analogValue to "true": The GTW seems to support 19 active subscriptions (or 20 total). Note that the first line in the Yabe list below (AI530) is not from HA and appears to be an erratic entry that I can't currently delete from the device. The Add-On subribed to all 19 objects with 28799s.

In the Add-On protocol, I see a ton of errors like: ERROR->BACnetIOHandler.py->create_subscription_task: Error while subscribing to device,1, analog-value,5295: resources: no-space-to-add-list-element

[CV-Private]

I have then removed two subscriptions and added the AV_1688 subscription. However, when trying to send the AV_1688 value from HA, I'm getting this new error:

This is in the HA system log of the error:

I'm also getting this error frequently:

[CV-Private]

Here's the Add-On logfile that I just downloaded: bacnet_addon_logs_2024-03-24.zip

It is quite interesting - it shows that the CoV subscriptions seem to work and that values are being retrieved by the Add-On.

However, when I look at the entities, I don't see the values being updated there. For example, when I look at AV_456, "varApPumpSpeed", then I see no variation in the plot, despite of many CoV updates in the log file:

In the Add-On WebUI, I saw the AV-459 presentValue occasionally changing between 60 and 61, but it is inconsistent with the present value shown in Yabe:

Another interesting finding is, that the Add-On has apparently re-subscribed after the first 8h. Here's the current subscription status in Yabe (5h lifetime left after the last re-subscription, 3h ago):

I can't identify the re-subscription event in the Add-On log file, though. It would be very useful to have timestamps in the Add-On log to be able to correlate log entries with other events.

Aside from the two HA system log error-types that I posted last night in my previous comment, I don't see a new bacnet-related error-type, but the error "Task exception was never retrieved" has occurred 667 times since I installed v0.1.6b5, which means that it probably occurs every minute. Any idea why it refers to "KeyError: 'analogInput:11'", which is the first object of the GTW-21? There's no active subscription on AI_011.

[GravySeal]

Would you mind sharing the json from the add-on while this error occurs? What happens when you reload the integration? Nothing should get removed after unsubscribing, so it's a little bit odd unsubscribing would be the reason for this error.

[CV-Private]

Do you mean the json captured with Weasel? Here it is: Weasel_2024-03-24.zip

This the Debug log from the Integration: home-assistant_bacnet_interface_2024-03-24T10-54-13.085Z.zip

I noticed in this Debug log that the KeyError is also referring to other analogInput objects. Could it be that the error occurs because the Integration is attempting to scan all objects in the background?

I just noticed that after the update to v0.1.6b5, I did NOT deactivate all Bacnet entities except AV_1688, which is what I did before. So, I could imagine that the Integration is now attempting to frequently scan each of the 1279 BACnet entities, which was not needed in previous tests because they were all deactivated except one.

I didn't deactivate the entities because I set the CoV subscription for analogValues to "true" in the configuration, and therefore I thought I should leave all entities active.

[GravySeal]

I see at 2024-03-23 23:31:08.250 in the debug log a strange happening. I don't know what Home Assistant is doing here, but since this log message, the errors started happening. I think it's again integration related, as the latest message in the websocket was correct.

If you reload the integration (or restart HA), what happens?

[CV-Private]

After re-loading the Integration, the AV_1688 is getting updated in both directions, HA Entity => Controller and Controller => HA Entity.

Also the AV_459 is now being updated - I see it changing every few seconds in this field:

I'll keep watching it - hopefully it remains like that.

[CV-Private]

It is becoming nice now! Here are the charts of the forward/return water temperature values AI_403 and AI_404 over the last 3 hours, which means that the CoV mechanism is working:

I noticed that you pushed Interface v1.4.0b4. I haven't yet installed it because I'm waiting for the next CoV re-subscription to see how that goes.

I'm wondering now: if my GTW-21 device only supports 20 CoV subscriptions, but there are more objects that I'd like to read occasionally, how can I do that?

Ideally, there should be a configurable scan interval per object, for those objects that are not being subscribed to. For example, like I can do it with the Modbus sensors of my solar panels:

Some values need to be updated more frequently, such as momentary power, whereas other don't need to be updated often - maybe once per minute, hour or even per day. Therefore, a single update interval for all objects would cause a lot of unnecessary data traffic on the network.

[GravySeal]

Currently there's no way to read individual objects faster than others, but it might be useful to implement later. I recommend starting a thread at the Discussion page of the add-on for feature requests. This way all ideas can be gathered in a central place and discussed.

[CV-Private]

Ok, I opened a new discussion there. For the HA restart issue, I opened a new Issue.

[CV-Private]

I just updated to the Add-On version 1.4.0 after seeing the notification in HA. I assume this update supersedes 1.4.0b5, right?

1) I found that the Add-On isn't yet "update-resistant". After the update, my previous subscriptions were gone and I had to restore them manually and reload the Integration. Here is the log from the Integration that I saved before reloading it. There's a bunch of errors at the end: home-assistant_bacnet_interface_2024-03-28T09-27-44.754Z.zip

2) I saw that you added the "Entities to BACnet objects" field - very nice! However, I wouldn't be able to understand from the documentation what syntax the entries must have. I'd suggest that you add some examples of valid entries. Maybe if you could add a link to the documentation under that field, it help the user to find out how to use that field.

3) The purpose and usage of the "Segmentation Supported" field is unclear and not explained in the documentation. In what case would it make sense to use a non-default setting?

[wamber2011]

[Uploading home-assistant_2024-04-29T11-53-16.454Z.log…]()