Sending packets at a high rate 'feels' wrong, and does increase the chances of seeing some odd effects when the network latency spikes occasionally. In this instance, the fact that you're in a development cycle means that any period much above 10-30 sec will start to become painful to debug or adjust.
Batching up the readings is one option, or you can decimate (sample rate reduce) your readings before uploading them (depending on the application). You can also apply a rate-adaptive approach if there are some events that you want to be able to post-process more precisely.
At the highest level of 'not much change', you still probably want to see that the endpoint is alive, so even if you only used daily averaged/processed data, making an upload every hour might make some sense. If you want to measure occupancy, maybe anything over a 10% change would justify an instant update.
If you do anything other than a simple periodic update, consider what the worst case fault condition might look like. Even though a broken sensor won't burn through your monthly broadband allowance, it could cause some effects on your LAN which are inconvenient. It's always useful to think about the extra steps which you would take if this project made it to volume deployment, or if it becomes an exploit target.