Welcome to Animus Talk

This is where users of Animus Heart can share ideas,
solve problems and inspire fellow enthusiasts.

Animus Heart?

Data usage limitation?

Developers
#1

I wounder why there is a limitation on Rest Requests (1000/24h) and Websockets messages (7000/24h)? Does really local area requests/messages need to be limited?

I’m interested in collecting sensors data (temp, humidity, light, co2, etc) and tried to use API websockets. Pretty quickly i hit the limit due to power reporting units in my network (e.g. QUBINO Flush 1 Relay).

A MQTT Broker solution would be really neat solution to be able to subscribe to only interesting data from the heart. Maybe i can turn of consumption reporting on my spamming devices but it feels a bit tediously.

8 Likes
#2

Indeed, I also have this question. I don’t understand why a read operation needs to be limited. If it were writing stuff, sure… Please explain?

1 Like
#3

From what I’ve heard this was to prevent premature failure of the internal storage due to consecutive writing. Not sure if this is true or not and beeing this conservative is really needed. Perhaps a dev could chime in?

Could be resolved by writing whatever needs to be stored to RAM instead or dumping the needed writes to a USB-stick for those of us that want to really hammer that API.

2 Likes
#4

I’ve played with the websocket api, and by connecting to the events endpoint (/heart/events) you can catch all sensor events without using your request quota (well, one message is used for authentication). Or maybe I’m missing something, like you won’t get all data through this “event stream”?
I only got one telldus thermometer and one zwave switch, but i get all values from these two.

1 Like
#5

This is one part of the reason, yes. Another reason is that the same API will be used from the cloud and a limit must be set to not overload the servers. We understand that this doesn’t affect when you run locally but it’s a preperation for the cloud requests as well.

1 Like
#6

Thanks for the explanation @vato ! But wouldn’t it be possible to lift this if running locally? It must be possible to detect quite easily? Or is the internal storage really that fragile that this has to be in effect regardless?

1 Like
#7

It’s not difficult to know if the request comes locally or remotely. The API is still in beta and before knowing the limitations we have choosen to restrict the amount of requests so that the users don’t overload their Hearts and at worst case break them.

#8

Have i understood correctly that the websocket “event stream” is without any limitations? Not even ping seems to count?

#9

Sorry for the late reply @jon, the websocket has a limit of events as well, ping included in the limit.

#10

I started to suspect that. Maybe i just didn’t notice that the counter actually increase when i was just testing stuff.

Imo the “event stream” is useless if data pushed from the heart is counted towards the limit. If i have a lot of sensors of any kind it will fill up quickly, since i cannot filter the events.

2 Likes
#11

I’m only having one temp sensor that triggers three different events (2 temperature, 1 humidity) and one zwave switch that triggers four events (but not so often). In 24h this gives me ~2.5k messages per day (ping and authorization included). Unfortunately i get disconnected a lot, so there is a lot of “unnecessary” authorization going on as well.

#12

I ran into this problem today as well. I’m just starting out on my home automation journey and have written a small python hack that is running on a raspberry pi. This hack does two things by listening to the events sent by the heart through the websocket connnection:

  1. Acts as a relay to control my Rusta/Sartano/Kangtai 433Mhz sockets that are not (yet?) supported natively by the heart.
  2. Stores all measurements to an influxdb database so that I can visualize measurements over time using chronograf and Grafana

Before today, I didn’t have that many devices generating that many messages, so I managed to stay under the 7000 messages per 24 hour limit. But today, I received my espresso machine with a PID controlled boiler. The PID control ensures a stable temperature in the boiler with short bursts of electricity to the heater element. This generates a lot of messages from the smart socket and after a couple of hours, I had hit the message limit :sob:.

I completely agree with Jon that this limit makes the websocket API pretty much useless. I understand the need for a request limit for cloud messages to reduce the risk of overloading the cloud service, but for messages within my local network, this limit makes no sense at all to me. Especially considering that these are messages sent by FROM the heart. Also, ping messages shouldn’t be counted since they are required to keep the connection open. (actually, the ping messages are completely unnecessary since there is support for ping messages in the websockets protocol that the heart does respond to, but seems to ignore since it closes the connection anyway, but I wrote about this in a separate thread)
The API request limit for requests within my own network, at least as it is right now, feels in my opinion completely arbitrary, artificial, useless and quite frankly super frustrating…:confounded:

1 Like
#13

I just got this. Please remove this limit. This is outrageous that i just bought this for a specific job, and its set to limit itself on that job. If there is an issue with it being that fragile, just put a clear warning in the beginning of the documentation, and add work towards an update to implement what “voltagectrl” user suggested: “Could be resolved by writing whatever needs to be stored to RAM instead or dumping the needed writes to a USB-stick for those of us that want to really hammer that API.”.

I gracefully ask that please patch this on the next update immediately.

Edit:
I have no uses for any cloud system, as I have my own. I mean to completely remove the restriction from local. I understand and respect your need for limiting cloud API calls.
But this seriously should be removed on the next patch. Or just release a hot fix. This is important to me that its “fixed” asap.

4 Likes
#15

Are there any plans to address this in the 3.0 release that was just announced? I’m someone who’s been looking at the Animus Heart for quite some time now, but being a software developer and embedded systems enthusiast I’m still holding off to see in which direction this issue is heading.

The API is still in beta and before knowing the limitations we have choosen to restrict the amount of requests so that the users don’t overload their Hearts and at worst case break them.

It’s soon a year since the Beta comment was posted, so I’m wondering if you might have gained some more insights by now, being able to deliver a more certain answer for what the future has to offer in regards to these API limitations. :slightly_smiling_face:

2 Likes
#16

If anyone is wondering: the api limitation was NOT addressed as of 3.0.1.

My current solution was coding another program to cache data received from Websocket data as it has a limit of 7000 messages. It not only costs you to query data, but to keep the connection alive with a NOOP packet, but for now, it keeps well bellow 7000 messages. Extra note: need to send a NOOP packet every 30 secs, so in one day, you use 2880/7000 messages just of NOOPs

It works for me, but I am highly displeased from the extra hours I had to put into the project.

Regards,
Zananok