@member01, 4 hours per day of sampling at, say, one sample every second to fit within the one-publish-per-second limit makes for 14,400 data points per day or more if sampling is more that than. I can assume that equipment will not be used solidly for 4 hours so if you were using a photon it would need to wake, connect to wifi and the cloud, send its data for the duration of the activity and go back to sleep. It could be sending data a lot or not. You need to characterize this. Predicting battery life under these conditions is impossible without a “model” and I suggest building a prototype to do testing.
Ultimately, you may need to consider using a lower power device like BLE, nRF24 or LoraWan. Each of these presents different challenges, especially with 50-100 devices.
Another approach you may want to consider is to have a simple BLE peripheral on each piece of equipment that announces the accelerometer data whenever it moves. These would be very low power. The gym member would wear a device with a battery that only needs to last for their time at the gym and can be recharged after each session. The device would have a Photon and BLE radio (eg. Redbear Duo or Photon/Bluz combo) and it would listen for the specific BLE announcements from the equipment, peel the accelerometer data from it and publish it to the cloud to be picked up by the rPi or other server. The challenge with the approach is to pick up only the nearest (being used) BLE device and not any adjacent ones.